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1.0  Scope. 

This  software  reusability  study  technical  report  is  delivered  under  contract  no.  N613 19-91- 
D-OOOl,  Delivery  Order  Number  0048,  for  the  Simulation,  Training  and  Instrumentation 
Command  (STRICOM),  Naval  Air  Warfare  Center,  Training  Systems  Division,  Orlando, 
FL.  Tliis  study  addresses  the  potential  reusability  of  the  Advanced  Rotary  Wing  Aircraft 
(ARWA)  test  bed  software  in  the  Aviation  Combined  Arms  Tactical  Trainer  (AVCATT) 
environment  Ground  vehicles,  other  types  of  aircraft,  or  other  types  of  military  training 
simulators  are  not  part  of  the  scope  of  this  study.  However,  it  would  be  expected  that  any 
system  with  similar  architecture  could  reuse  significant  portions  of  the  software. 


1.1.  Purpose. 

The  purpose  of  this  study  is  to  provide  the  customer  with  enough  information  to  make 
ARWA  development  decisions  which  may  impact  future  development  efforts  in  the 
ARW.VAVCATT  realm.  For  instance,  in  future  contracts  S  flllCOM  will  be  able  to 
reque.st  a  particular  level  or  percentage  of  reuse  when  adding  ARWAs  to  die  Aviation  Test 
Bed  (AVTB)  and  be  knowledgeable  about  the  best  approach  toward  reaching  that  level  of 
reuse  and  productivity.  To  support  this  goal,  this  study  contains  quantitative  data  on  the 
level  of  reusability  potential  of  the  ARWA  system,  including:  costs,  savings,  and  schedule 
impact. 

In  addition,  the  findings  in  this  study  shall  also  provide  explicit  information  that  will  boost 
the  level  of  software  reusability  in  the  ARWA  system,  especially  during  Phase  II. 

1.2.  Background. 

STKICOM  requested  that  this  study  be  performed  during  Phase  I  of  the  ARWA  delivery 
order  in  parallel  with  the  requirements  and  preliminary  design  phases  of  the  effort.  The 
Statement  of  Work  (SOW)  asked  that  this  study  "determine  how  reusable  the  ARWA 
software  will  be  if  developed  in  accordance  with:" 

a .  Existing  ModSlM  architecture 

b.  Recommendations  from  the  Institute  for  Defense  Analyses  (IDA),  U.S.  Army 
Communications-Eleclronics  Command  (CECOM),  Georgia  Institute  of 
Technology  (GIT),  and  Software  Engineering  Institute  (SEI)  studies  (MOTE: 
The  SEI  study  occurred  after  the  SOW  was  written.) 

c.  The  Software  Productivity  Con-sortium’s  (SPC’s)  Ada  Style  Guide  (SPC- 
9!U61-CiVlC). 

NOTE:  It  is  assumed  m  this  report  th-at  "how  reusable"  refers  to  the  quality  (maturity  level) 
and  percentage  of  the  product  which,  will  be  reusable  within  the  same  domain  if  certain 
actions  are  taken,  and  that  "ease  of  reuse"  will  translate  into  labor  hours  saved,  i.e., 
productivity.  Even  though  only  software  is  mentioned,  it  is  also  assumed  that  the  term 
“tcii.^able”  refers  to  any  software  workpioduct,  tool,  or  process  that  can  be  used  again  in 
aauiiicr  situation  (i.e.,  software  system,  context,  etc.)  with  0  to  25  percent  modification 
made  to  the  existing  object/idea  that  is  going  to  be  reused. 

The  second  item  to  be  addressed  is  the  cost  and  schedule  impact  when  implementing  (a) 
and  (b)  above,  plus  the  cost  and  schedule  impact  to  reach  higher  levels  of  reuse  via  otlier 
reuse  activities. 
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1.3.  Document  overview. 

Scope.  This  section  covers  the  purpose,  scope,  and  background  of  this  study. 

Referenced  documents.  Several  industrial  publications  and  internal  Loral  documents  are 
listed  in  this  section  as  key  references  cited  in  the  paper. 

Procedures.  The  current  and  suggested  reuse  implementation  plans  are  delineated  in  detail. 
The  assumptions  and  procedures  for  analyzing  &e  reuse  level,  resulting  quality,  cost,  and 
schedule  impact  of  each  of  these  implementation  activities  are  described. 

Re.sults.  The  results  from  analyzing  each  implementation  activity  is  summarized  in  this 
section. 

Conclusions  and  recommendations.  This  section  summarizes  the  key  conclusions  and 
recommendations  regarding  the  most  cost  effective  approach  for  achieving  the  most  reuse 
in  the  ARWA  domain. 

Notes.  An  acronym  list  and  a  short  glossary  of  critical  terms  used  in  this  paper  are 
included  in  this  section. 

Appendices.  These  include  detailed  iiiformation  on  reuse  guidelines,  reuse  tools,  and 
models  used  for  Verifleation  &  Validation  (V&V)  that  will  be  used  during  subsequent 
phases  of  this  project 

Appendix  A  describes  the  model/data  searches  for  validating  the  two  ARWA 
simulations,  including  the  selection  criteria. 

Appendix  B  contains  general  reuse  gui^lines  for  design  and  coding  in  Ada.  These 
are  stored  in  the  programmer’s  notebooks  and  have  been  shared  with  the  designers. 


2.0  Referenced  documents. 


The  following  documents  are  referenced  within  this  report. 

I-Alexandiis  86]  Alexandris,  N.  February  1986.  “Adaptable  Software  and 

Hardware  Problems  and  Solutions.”  Computer.  Vol.  18.  No.  2. 
pp.  29-39. 

[Boeing  93J 

Boeing.  1993.  "DARTS:  A  Domain  Architecture  for  Reuse  in 
Training  Systems."  Huntsville,  Alabama. 

[CECOM93J 

CECOM.  April  1993.  "While  Prqper  for  the  Advanced  Rotary  Wing 
Aircraft  Software  Design  Review.”  Leavenworth,  Kansas. 

[Gaffney  89] 

Gaffney,  J.,  An  Economics  Foundation  for  Software  Reuse, 
SW_REUSE_ECONM-89040-N,  SPC,  July  1989 

[GIT93] 

GIT.  April  1993.  "Independent  Assessment  of  the  Advanced 
Rotary  Wing  Aircraft  (RWA)  Software  Design  for  STRICOM." 
Atlanta,  Georgia. 
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[Hooten  89]  Hooten,  M.  1989.  Software  Reuse  Methodology  and  Checklists. 

FACC-TR-1113.  Ford  Aerospace/Space  Information  Systems 
Division.  (Now  Loral  Space  Information  Systems.)  Houston, 
Texas. 

[IDA  93]  Brykczynski,  B.  and  D.  Robert  Worley.  April  1993.  "An 

Evaluation  of  the  ModSIM  Architecture  and  RWA  Design." 
Institute  for  Defense  Analyses.  Alexandria,  Virginia. 

[Lea 93]  Lea,  D.  November  1993.  WISR’93  Design-for-Reuse  Working 

Group  Report.  Workshop  on  Institutionalizing  Software  Reuse  held 
on  November  1-4, 1993.  IBM.  Owego,  New  York. 

[Ogush  93]  Ogush,  M.  1993.  “C  Design  and  Coding  Guidelines  for  Reuse." 

Hewlett-Packard.  Palo  Alto,  California. 

[Pamas  et.  al.  89]  Parnas,  D.,  P.  Clements,  and  D.  Weiss.  1989.  “Enhancing 
Reusability  with  Information  Hiding.”  Software  Reusability  Vol.  I  - 
Concepts  and  Models.  Association  for  Computing  Machinery 
Press,  pp.  141-157. 

[Pamas  72]  Pamas,  D.  December  1972.  “On  the  Criteria  to  be  Used  in 

Decomposing  Systems  into  Modules.”  Communications  of  the 
ACM.  Vol.  15. 

[SEI 93]  SEI.  July  1993.  "Review  of  the  Advanced  Rotary  Wing  Aircraft 

Software  Specification."  Pittsburgh,  Pennsylvania. 

[SPL  90]  SPL.  November  1990.  Corporate  Productivity  Lab  Standards  and 

Methods  Document,  Ada  Standards,  Volume  6.  SPL_Ada_STDS- 
90023-M.  Version  1.0.  Loral  Softwaie  Productivity  Laboratory. 
San  Jose,  California,  section  1,  p.  127-175.  Section  2,  pp.  45-55. 


3.0  Procedures 

This  study  was  performed  by  software  engineers  with  reuse  expertise,  coordinating  inputs 
from  cognizant  Advanced  Distributed  Simulation  Technology  (ADS17  software  managers 
and  designers,  and  from  published  data  produced  from  in-house  and  industry  reuse  efforts. 
The  first  step  v/as  to  establish  a  baseline  of  current  reuse  within  the  system  being  delivered 
by  the  Loral  team  and  then  define  tlie  additional  reuse  activity  options  that  STRICOM 
should  consider.  These  options  stem  from  the  SOW  and  current  reuse  philosophy.  The 
next  step  was  to  evaluate  the  baseline  and  each  option  according  to  the  resulting  reuse 
maturity  level,  quality,  cost,  and  schedule  impact,  if  implemented.  Numerical  rating 
schemes  were  used  to  rate  each  option  so  that  the  best  choice(s)  would  be  easily  identified 
by  the  highest  total. 

3.1.  Description  of  current  reuse  efforts. 

The  Loral  team  is  applying  six  reuse  techniques  so  that  the  delivered  systems  will  contain 
fairly  robust  reuse  features  without  affecting  the  current  cost  and  schedule.  These 
techniques  are: 
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a.  Generic  architecture.  Conform  to  the  generic  Modular  Simulation 
System  (ModSIM)  architecture  as  much  as  possible. 

b.  External  reuse.  Search  existing  libraries  for  off-the-shelf  software 
models/algorithms,  specifications,  test  scenarios,  database  mapping 
data,  etc.  that  could  be  reused  in  the  ARWA  Simulator  System. 

c.  Internal  reuse.  Reuse  existing  in-house  designs  and  software  from 
related  simulation  projects. 

d.  Standard  processes.  Provide  subcontractors  with  the  same  process  and 
tool  scripts  used  to  count  non-commented  source  lines  of  co^  (LOG). 

e.  Uniform  standards.  Establish  reuse  design  and  coding  principles  to  be 
used  by  the  development  team. 

f .  Tool  checker.  Use  software  tools  to  check  adherence  to  the  Ada  style 
guidelines. 

Reasoning  for  generic  architecture  fa).  ModSIM  is  a  generic  simulator  architecture  which 
defines  a  standard  functional  breakdown  of  a  simulator  system  into  12  segments  and 
defines  standard  interfaces  between  those  segments.  Tlie  12  segments  are  as  follows; 
Flight  Station,  Flight  Controls,  Flight  Dynamics,  Propulsion,  Navigation/Communication, 
Weapons,  Radar,  Sensors,  Physical  Cues,  Visual,  Aircraft  Survivability  Equipment, 
Control,  and  Environment.  One  or  more  segments  may  be  grouped  on  the  same 
computational  platform  to  form  a  module.  Intersegment  communication  in  ModSIM  is 
accomplished  by  means  of  a  message  based  architecture.  Each  segment  communicates  over 
a  virtual  network  (VNET),  which  can  be  either  through  shared  memory  or  over  a  physical 
network.  By  conforming  to  the  ModSIM  architecture,  this  simulator  will  be  more  easily 
maintainable  in  that  those  familiar  with  ModSIM's  generic  architecture  will  understand  its 
design.  The  modular  nature  of  the  system  facilitates  accurate  updates  to  the  system, 
especially  since  the  modules  are  highly  cohesive  and  loosely  coupled  (i.e.,  have  few 
intermodular  interfaces). 

Status  of  (al.  According  to  the  organizations  that  performed  an  independent  evaluation  of 
the  ARWA  architecture  last  year,  die  ARWA  design  conforms  to  the  ModSIM  architecture 
with  some  minor  variations  in  the  grouping  of  segments.  The  ARWA  architecture 
separates  the  Visual  and  Flight  Station  segments  into  distinct  modules  -  the  Visual  System 
Module  (VSM)  and  the  Flight  Station  Module  (FSM),  respectively  -  and  groups  the 
remaining  ModSIM  segments  into  the  Simulator  System  Module  (SSM).  Figure  1  depicts 
both  the  ARWA  architecture  and  the  generic  ModSDvl  architecture. 
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Rpaiwniny  for  external  reuse  fbV  The  assumption  is  that  reused  assets  will  be  reusable  in 
future  applications  of  the  simulator.  This  is  true  if  the  reused  artifacts  fulfill  requirements 
that  are  not  likely  to  change  across  ARWAs  or  over  a  long  period  of  time  within  the 
aviation  simulator  training  world. 

Status  of  fb’t.  The  Loral  team  identified  a  list  of  software  models  which  would  be  usable  in 
the  ARWA  simulation  system,  as  well  as  those  needed  to  validate  the  accuracy  of  the 
simulation  software.  Refer  to  Appendix  A  for  a  listing  of  repositories  searched  and  the 
results  of  those  searches. 

Reasoning  for  internal  reuse  (cY  Internal  reuse  is  defined  as  reusing  software,  data,  and 
documentation  from  existing  Loral,  Boeing,  and  McDonnell  Douglas  Helicopter  Systems 
(MDBS)  efforts,  as  opposed  to  obtaining  this  information  from  external  repositories. 
These  systems  were  not  necessarily  designed  for  reuse,  but  reuse  is  relatively  simple 
because  the  developers  are  already  familiar  with  the  architecture  and  software. 

Status  of  (c).  Boeing  and  MDHS  have  already  identified  much  software  which  can  be 
applied  to  the  ARWA  project,  such  as  the  Fly  Real-Time  (FLYRT)  flight  model  and  the 
Bus  Interface  Unit  (VNET  segment  interface).  Much  of  Boeing's  reusable  software  has 
been  obtained  from  Boeing  Helicopter's  Comanche  Engineering  Development  Simulator. 
Much  of  MDBS's  reusable  software  has  been  obtained  from  MDBS's  Apache  Engineering 
Simulator.  Tables  1-3  identify  the  lines  of  code  estimates  as  well  as  the  amount  of  reusable 
software  expected  for  the  ARWA  simulator  system. 

Reasoning  for  standard  processes  fdl.  In  a  multi-developer  team  environment,  it  is 
important  that  all  parties  follow  the  same  processes  in  oi^er  to  ensure  that  the  delivered 
system's  progress  can  be  tracked  and  communicated  in  the  same  way. 

Status  of  fdl.  One  critical  example,  is  the  way  LOC  estimates  were  being  made  and 
reported.  Loral  provided  a  standard  methodology  for  counting  and  reporting  their  progress 
using  estimated  and  actual  LOC  data.  One  way  to  ensure  accurate  counts  was  to  supply  all 
of  the  subcontractors  with  the  same  in-house  code  counter  scripts  for  Ada,  FORTRAN, 
andC.  Hiis  was  very  successful. 

The  Loral  development  process  has  also  been  communicated  to  the  team  via  the  process 
chart  shown  in  figure  2.  More  is  accomplished,  more  quickly  when  all  of  the  team 
members  use  the  same  spiral  development  strategy. 


Segment 

Name 

Subsystem  Name 

Reused 
Code  (LOC) 

Total  Code 
(LOC) 

%  Reused 

VSM 

VSM  Network  Interface 

0 

2,0G0 

0% 

VSM  User  Interface 

0 

6,000 

0% 

VSM  Hardware  Interface 

0 

10,000 

0% 

Process  Scheduler 

0 

44,000 

0% 

TOTAL 

0 

wm 

Table  1.  Reuse  LOC  Estimates  for  Common  ARWA  SS 
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Segment 

Name 

Subsystem  Name 

Reused 
Code  (LOC) 

Total  Code 
(LOC) 

%  Reused 

FSM 

FSM  Control 

0 

2,500 

0% 

Support  Functions 

0 

4,500 

0% 

Aircraft  Systems 

0 

250 

0% 

Real-Time 

0 

800 

0% 

I/O  Linkage 

0 

920 

0% 

Control  Load  Linkage 

0 

460 

0% 

Flight  Station  Display  Sys 

0 

1,500 

0% 

TOTAL 

IIIBilllllli 

BIS 

■  ■ 

0  % 

SSM  Control 

Sim.  Mod.  &  State 

275 

1,000 

27% 

Parameter  Mod. 

0 

450 

0% 

Simulation  Synchronization  & 
Tuning 

0 

660 

0% 

Executive 

0 

1,500 

0% 

SSMTNE 

Control 

0 

2,595 

0% 

Intervisibilitity 

7,500 

25,000 

30% 

Weapons 

4,000 

1,000 

80% 

SSM  BIU 

4,840 

100% 

TOTAL 

16,615 

41,045 

40  % 

Support 

Subsystems 

Session  Manager 

0 

5,438 

0% 

Operational  &  Logistic  Support 

3,168 

5,280 

60% 

Mission  Planning 

2,900 

5,800 

50% 

ModSAF 

250,000 

250,000 

100% 

After  Action  Review 

7,000 

10,000 

70% 

ARWA  LAN 

0 

790 

0% 

TOTAL 

281,179 

94  % 

GRAND  TOTAL 

1  279,683 

410,654 

68  % 

Table  1.  Reuse  LOC  Estimates  for  Common  ARWA  SS  [Continued] 
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Segment  Name 

Reused  Gode 
(LOG) 

Total  Gode  (LOG) 

%  Reused 

Nav/Gomm 

0 

2,100 

0% 

ASE 

0 

2,125 

0% 

Physical  Gues 

0 

725 

0% 

Sensors 

0 

2,815 

0% 

Flight  Gontrols 

775 

1,550 

50% 

Weapons 

500 

2,000 

25% 

Flight  Dynamics 

4,395 

5,170 

85% 

0 

600 

0% 

TOTAL 

5,670 

17,085 

33% 

Table  2.  Reuse  LOG  Estimates  for  RAH-66  Kit 


Segment  Name 

Reused  Code 
(LOG) 

Total  Code  (LOG) 

%  Reused 

Nav/Comm 

1,820 

2,800 

65% 

ASE 

320 

640 

50% 

Physical  Cues 

1,440 

1,920 

75  % 

Sensors 

2,240 

50% 

Flight  Controls 

2,080 

50% 

Weapons 

1,000 

4,000 

25% 

Flight  IDynamics 

1,184 

2,368 

50% 

Propulsion 

800 

1,600 

50% 

TOTAL 

8,724 

17,648 

49% 

Table  3.  Reuse  LOG  Estimates  for  AH-64D  Kit 
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Module/Sub- 
System  Name 

Reused  Code 
(LOC) 

Total  Code 
(LOC) 

%  Reused 

JJas^ 

Kit 

Base 

Kit 

Base 

Kit 

SSM  Base  Code 

SSM  Kit  Code  1 

16,615 

7,200 

41,045 

17,365 

40% 

41  % 

FSM  Base  Code 

0 

20,760 

0% 

FSM  Kit  Code  1 

0 

3,670 

0% 

VSM  Base  Code 

0 

60,800 

0% 

VSM  Kit  Code  2 

0 

3,200 

0% 

Device  Snb- 
Totals 

16,615 

7,200 

129,475 

24,235 

14% 

30%  I 

DIS  Support  Sub- 
Systems  Base  Code 

263,068 

281,179 

94% 

DIS  Support  Sub- 
Systems  Kit  Code 

225 

1,100 

25% 

Cell  Sub-Totals 

279,683 

7,425 

410,654 

25,335 

68% 

29% 

GRAND  TOTAL 

287,108 

435,989 

66  % 

Notes:  ^  Average  of  ttae  AH-64D  and  RAH-66  software  kits. 

^  Kit  specific  code  estimated  at  S  %  of  total  VSM  code. 


Table  3.1  Reuse  LOC  Estimates  for  Base  and  Kit 


Table  3.1  summarizes  the  reused  line  of  code  for  the  common  software  of  the  bases  and  the 
aircraft  specific  software  code  of  the  aircraft  kits.  The  common  software  of  the  bases  and 
some  of  the  aircraft  .specific  kit  code  is  reusable  for  future  experiments  and  aircr.sft 
implementations. 
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Rfsasoniny  for  uniform  iitandards  (eV  Standards  ensure  that  a  system  will  look  and  act  m 
accordance  with  the  requirements  supported  by  the  standard.  In  this  case,  a  uniform  set  of 
reuse  design  and  code  standards  will  ensure  that  portions  of  the  delivered  system  will  be 
reusable  easily  maintainable. 

.Status  of  (el.  Each  developer  in  the  Loral  team  received  a  set  of  reuse  &sign  and  cotte 
guidelines  such  as  those  contained  in  appendix  B. 

Rea.sontny  for  tool  checker  (f>.  A  tool  checker  saves  time  in  verifying  code  adherence  to 
standards. 

Statu.s  of  ffi.  The  Loral  team  plans  to  use  the  SPC's  Ada  Style  Guidelii^  as  contained  in 
Loral's  corporate  Ada  Style  Guidelines  [SPL  90].  Loral  also  has  several  software  tools 
that  automatically  check  the  conformity  of  Ada  source  code  to  most  of  the  Ada  Style 
Guidelines. 

3.2.  Description  of  reuse  options. 

The  models  used  in  this  study  focus  on  the  effects  of  reuse  on  productivity  to  produce  the 
system.  This  study  also  extends  the  model  to  estimate  future  productivity  renting  from 
specific  reuse  activities  beyond  the  events  mentioned  in  the  SOW.  Other  factors  considered 
in  this  study  include  the  level  of  reuse  maturity  and  the  number  of  times  something  is 
reused. 

Reuse  implementation  is  more  than  just  a  technical  issue,  i.e.,  knowledge  of  the  domain. 
Successful  reuse  entails  proper  management,  guidelines,  standard  processes,  training, 
tools,  configuration  management,  and  handling  of  legal  issues. 

3.2.1.  Independent  study  suggestions. 

Four  independent  studies  were  funded  by  STRICOM  and  conducted  by  the  following 
agencies:  (1)  Institute  for  Defense  Analyses  (IDA),  Alexandria,  VA  [IDA  93],  (2) 
Communications-Electronics  Command  (CECOM),  Research,  Development  and 
Engineering  Center,  Software  Engineering  Direetorate,  Training  &  Maneuver  Systems, 
Leavenwoi^,  KS  [CECOM  93],  (3)  Georgia  Institute  of  Technology  (GIT),  Atlanta,  GA 
[GIT  93],  and  (4)  Software  Engineering  Institute  (SEI),  Carnegie  Mellon  University, 
Pittsburg,  PA  [SEI  93].  These  agencies  addressed  the  same  set  of  questions  regarding  the 
generic  ModSlM  System/Segment  Specification  (SSS)  and  ARWA  designs.  These 
questions  dealt  with  die  degree  of  design  conformity  to  the  ModSIM  SSS,  modularity,  and 
adherence  to  object-oriented  principles  by  the  ARWA  SS  architecture  in  its  incomplete  state 
as  of  February  1993.  Each  independent  evaluator  was  given  a  22  volume  set  of  documents 
which  included  Rotary  Wing  Aircraft  (RWA)  design  data,  unit  development  folders 
(UDFs),  preliminary  design  review  (PDR)  slides,  and  preliminary  design  materials. 

The  first  question  asked  “Is  the  System/Segment  Specification  for  the  Generic  Modular 
Simulator  -  Specification  #S493-10400C  tnily  modular,  reusable,  and  object-oriented  in  the 
design  architecture  presented?”  The  SEI  report  stated  ”The  Generic  Modular  Simulator 
System  (MSS),  as  presented  in  the  System/Segmentation  Specification  is  indeed 
modular.”.  ”The  RWA  Step  1  specification  is  a  proof  by  existence  Aat  the  specification  for 
Generic  MSS  is  reusable.”,  and  ’The  MSS  .spaciTicaHon  is  modular  and  has  some  attributes 
of  the  idemity  and  classification  object-oriented  characteristics.”  The  IDA  report  stated  ”We 
found  the  ModSIM  architecture  to  be  reasonably  modular.”  The  CECOM  report  stated  ’To 
the  level  of  detail  which  was  addressed  in  the  System/Segment  Specification,  the  design 
architecture  is  modular.”.  ”The  design  architecture  outlined  by  the  System/Segment 
Specification  presents  an  architecture  which  could  be  easily  tmlored  to  particular  flight 
simulator  applications.”,  and  ”The  design  architecture  partitioned  the  system  along 
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functional  lines.”  The  GIT  reported  stated  "The  System/Segment  Specification  for  the 
Generic  Modular  Simulator  -  Spec.  #  S49S-10400C  is  truly  Modular.  Reusable  and  Object 
Oriented  in  the  design  architecture  presented." 

The  second  question  asked  “Does  the  design  described  in  the  RWA  Step  1  report  comply 
widt  the  MODSIM  guidelines/approach  (defined  in  the  System  Segment  Specifications  for 
the  Generic  Modular  Simulator  -  Specification  #S49S-1()4(X)C)T’  The  SEI  report  stated 
"The  specification  in  the  RWA  Step  1  documentation  complies,  for  the  most  part  with  that 
presented  in  the  MSS  Generic  specification."  and  "It  is  clear  that  RWA  does  adhere  (both  in 
spirit  and  in  actuality,  to  the  extent  possible)  to  the  MSS  concepts/guidelines."  llie  IDA 
report  stated  "The  RWA  design  showed  a  hieh  degree  of  compliance  with  the  MODSIM 
architecture.”  .The  CECOM  report  stated  "The  Flight  Station  and  Visual  modules  map 
closely  to  the  modules  defined  in  the  MODSIM.  However,  the  RWA  SS  creation  of  the 
Simulator  System  Module  with  10  application  segments  deviates  from  the  MODSIM 
guidelines."  Tlie  GIT  report  stated  "Tlie  design  described  in  the  RWA  Step  1  report 
complic.s.  in  spirit,  witli  the  MODSIM  guidelin^approach." 

The  Uiird  question  asked  “Does  the  documentation  provided,  which  represents  the  RWA 
design  as  accomplished  by  Lxiral/Boeing  (i.e.,  unit  development  folders  and  other  design 
documentation),  comply  with  the  MODSIM  guidelines/approach?  Is  the  RWA  design 
modular,  reusable  and  object-oriented?"  The  SEI  report  stated  “The  RWA  specification 
closely  follows  the  Generic  MSS  specification  with  respect  to  modularity,  reusability,  and 
use  of  an  object-oriented  approach,  and  the  comments  made  about  the  MSS  specification 
with  respect  to  these  properties  also  hold  for  the  RWA  specification.”  The  IDA  report 
stated  “We  found  the  RWA  design,  like  the  MODSIM  architecture,  to  be  reasonably 
modular  but  not  based  upon  an  object-oriented  design."  The  CECOM  report  stated  "In 
general,  the  UDFs  were  not  at  a  point  where  an  assessment  of  the  code  modularity  could  be 
performed.",  "If  indeed  the  code  being  imported  is  usable,  the  code  should  remain  reusable 
for  other  applications.  The  design  was  not  far  enough  into  the  details  to  determine  if  any 
new  code  generated  would  be  reusable.”,  and  "This  approach  does  not  map  cleanly  into 
object-oriented  concepts.”  The  GIT  report  stated  "The  documentation  provided  which 
represents  the  RWA  design  as  accomplished  by  Loral/Boeing  (i.e..  Unit  Development 
Folders  and  other  design  documentation)  generally  complies  with  the  MODSIM 
guidelines/approach.”  and  "The  RWA  design  is  Modular  and  Ohject  oriented." 

The  fourth  question  asked  “Does  the  System/Segment  Specification  for  the  Generic 
Modular  Simulator  -  Specification  #495-10400C,  and  consequently  the  RWA 
implementation  of  MODSIM,  have  adequate  interface  definitions  to  be  implemented 
successfully  in  future  simulator  programs?”  The  SEI  report  stated  "The  requirements  for 
future  STRICOM  simulator  programs  are  not  known  by  this  review  team,  so  the  team 
cannot  .say  specifically  if  the  RWA  approach  will  be  adequate  for  these  programs.”  The 
IDA  report  stated  ”...  ,  we  were  unable  to  evaluate  whether  the  MODSIM  architecture 
provides  adequate  interface  definitions  to  be  implemented  successfully  in  future  simulator 
programs.”  The  CECOM  report  stated  "The  interface  definition  is  only  at  the  top  level. 
This  does  not  provide  the  detailed  information  required  to  ensure  successful  implementation 
in  cither  the  RWA  or  future  simulation  models.”  The  GIT  report  stated  "The 
System/Segment  Specification  for  the  Generic  Modular  Simulator  -  Spec.  #S495-104(X)C 
and  consequently  the  RWA  implementation  of  MODSIM  provides  a  fairly  detailed 
description  of  the  system  level  requirements."  and  ”...,  the  RWA  design  does  indeed  have 
a  significant  level  of  definition  in  its  interface  design.” 

Most  of  the  agencies  concluded  that  the  ARWA  SS  architecture  matched  the  generic 
ModSIM  architecture,  except  that  10  independent  segments  have  been  grouped  together  as 
the  SSM  module.  All  of  the  agencies  concluded  that  the  architecture  was  indeed  modular, 
but  pointed  out  that  the  design  did  not  fully  adhere  to  some  of  the  attributes  of  an  object- 
oriented  design. 
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Reusability  of  the  ARWA  was  also  addressed  by  the  studies.  The  agencies  generally  came 
to  the  conclusion  that  if  total  software  reuse  is  to  be  achieved  by  the  ARWA  project. 
STRICOM  must  include  reuse  requirements  in  the  sirecification  and  Loral  must  provide 
more  maintenance  documentation  to  make  reuse  easier  in  the  future. 

Some  segments  have  legacy  code  available  from  Loral,  Boeing,  and  MDHS  which  can  be 
reused  in  the  ARWA  program  in  their  current  state.  The  most  reusable  ARWA  modules  as 
determined  by  these  studies  and  Loral's  internal  reuse  estimates  (tables  1  -  3)  are  listed  in 
table  4  from  the  most  reusable  (listed  first)  to  the  least  reusable  (listed  last).  Those  modules 
with  close  to  no  current  reusable  value  in  their  current  state  are  not  shown. 


ARWA  Module  Name 

IDA 

CECOM 

GIT 

Loral 

Weapons 

V 

V 

V 

Flight  Dynamics 

V 

MM 

V 

V 

Sensor  Control 

V 

Bi 

yl 

(V) 

ASE 

V 

V 

(V) 

(V) 

TNE  (Environment) 

(V) 

V 

Flight  Control 

(V) 

V 

BIU 

V 

Nav/Comm 

(V) 

Visual  Systems  Module 

(V) 

Propulsion 

(V) 

NOTE:  A  parenthesized  check  mark  (V)  denotes  that  the  module  is  only  paitially  reusable. 


Table  4.  Segments  With  Existing  Reusable  Software 


If,  on  the  other  hand,  the  Army  is  willing  to  switch  to  a  more  object-oriented  architecture 
which  is  more  conducive  to  reuse  and  maintenance,  then  the  agencies  suggested  that  the 
specification  be  modified  to  include  reuse  and  object-oriented  requirements.  This  would 
change  the  flavor  of  the  contract  from  straight  development  into  a  reuse  development 
project. 

Since  conversion  to  an  object-oriented  design  is  a  separate  option,  the  analyses  will  refer 
only  to  the  structured  design  suggestions  by  these  studies. 

3.2.2.  Ada  style  guidelines. 

One  of  the  options  to  consider  is  the  use  of  the  SPC's  Ada  Quality  and  Style  Guidelines  for 
Professional  Programmers.  Loral's  software  expertise  provided  some  of  the  reusability 
and  portability  guidelines  which  were  incorporated  in  the  September  1991  version  of  this 
book.  These  guidelines  have  been  in  the  Corporate  Standards  and  Methods  Documents 
since  November  1990  and  have  been  in  use  on  Ada  projects  since  then.  Reusability  is 
ensured  by  these  guidelines  because  they  address  ways  to  handle  Ada  to  promote 
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understanding  and  clarity,  robustness,  adaptability,  independence,  and  key  portability 
issues. 

This  option  would  ensure  that  Loral  and  subcontractors  will  use  the  guidelines  during 
design  and  coding  phases.  The  Grammatech  Ada-Assured  tool  could  be  used  to 
automatically  check  consistency  with  those  guidelines,  especially  in  the  areas  of  portability 
and  reusability. 

3.2.3.  Port  to  Ada. 

Since  Ada  is  the  language  of  choice  by  the  Government,  and  it  has  some  desired  features 
which  support  reuse,  it  would  be  valuable  to  port  tl»  entire  simulator  system  to  Ada.  The 
Support  Subsystems  of  the  ARW A  project,  including  ModSAF,  includes  263,000  lines  of 
reused  'C  code.  The  SSM  common  software  contains  16,615  lines  of  reused  FORTRAN 
code.  The  RAH-66  kit  contains  25,770  lines  of  reused  FORTRAN  code.  Systems 
requiring  one  type  of  compiler  also  reduce  the  cost  of  maintenance  and  improve  system 
performance. 

3.2.4.  Domain  analysi.',. 

In  order  to  achieve  higher  levels  of  productivity  from  reuse,  one  must  work  at  higher  levels 
of  abstractions,  such  at  the  prelimin^  and  det^d  design  levels. 

Domain  analysis  of  the  ARWA  is  being  performed  to  establish  the  common  features  among 
both  dte  RAH-66  and  AH-64D  kits  in  order  to  determine  both  the  static  and  variable  aspects 
of  each  kit  From  this  information  and  the  architectures  of  the  ARWA  kits  for  the  RAH-66 
and  AH-64D,  a  generic  architecture  and  data  set  for  an  ARWA  is  being  created.  The 
current  designs,  in  some  cases,  use  different  models  to  accomplish  the  same  result  Each 
commonalty  needs  to  be  evaluated  for  genericity,  testability,  performance,  and 
extensability.  The  current  schedule  and  funding  permits  this  to  some  degree.  The  result  is 
a  design  and  data  set  template  that  contains  the  core  set  of  features  that  are  common  to  both 
the  RAH-66  and  AH-64D,  with  an  optional  set  to  accommodate  unique  features.  Such 
templates  would  facilitate  adding  other  rotary  wing  aircraft  (such  as  the  OH-58D)  to  the 
simulator  structure. 

Other  domains  such  as  U.  S.  Army  training  simulators  that  include  ground-based  vehicles 
and  simulators  could  be  explored  in  order  to  expand  the  distributed  simulator  network  to 
interface  with  the  ARV/A  SS  and  to  accommodate  combined  arms  military  training. 

3.2.5.  Object-Oriented  design  conveirsion. 

The  stnicturcd  ModSIM  architecture  constrains  object-oriented  design  and  reusability  to  a 
degree.  Inheritance  and  information  hiding  are  some  of  the  features  that  would  facilitate 
swapping  of  reusable  building  blocks  that  would  fit  into  the  architectural  frameworks 
(system  and  database  designs)  of  the  simulator  domain.  These  frameworks  would  easily 
be  used  in  automatic  simulator  generators,  like  those  on  the  market  today,  i.e.,  G2  made  by 
Microsoft.  The  number  of  object-oriented  methodologies  with  tool  support  is  rapidly 
increasing.  The  technology  is  improving  rapidly.  Two  acceptable  methodologies  are: 
Real-Time  Object-Oriented  Metliodology  (ROOM)  UiiU  Scblaer-Mellor.  Both  have  tool 
support,  i.e.,  ObjeetTime  and  Cadre,  respectively. 

One  option  would  be  to  estabMsh  a  parallel  effort  to  convert  the  entire  ARWA  design  tmd 
database  into  a  totally  object-oriented  architecture.  Hie  alternative  which  is  being  pursued 
is  to  convert  key  portions  of  the  design  and  database  into  an  object-oriented  structure.  This 
is  feasible  if  the  ^rtion  was  isolated  enough  from  the  rest  of  the  design  so  as  not  to  cause 
interface  problems.  For  example,  the  VSM  is  essentially  being  defined  from  fhe  ground 
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up,  which  affords  an  excellent  opportunity  to  explore  an  object-oriented  design.  In  this 
report,  while  discussing  object-oriented  conversion,  the  toud  conversion  option  is  being 
addressed. 

Another  option  would  be  to  start  implementing  Ada  9X  features  in  the  design  of  the  ARWA 
software  in  anticipation  of  its  release.  Accon&g  to  the  Memorandum  for  Secretaries  of  the 
Military  Departments  Directors  of  the  Defense  Agencies  concerning  Early  Use  of  Ada9X, 
dated  March  9, 1W4,  the  "revision  of  ANSI/MIL-STD-1815A  (Ada83)  has  progressed  to 
the  point  that  it  is  nearly  certain  that  the  new  version,  referred  to  as  Ada9X,  will  be 
approved  by  national  and  international  standards  bodies  during  1994.”  Hie  memorandum 
goes  on  to  say  that  "early  use  of  Ada9X  provides  access  to  the  language's  many 
enhancements,  including  full  support  for  object-oriented  programming,  enhancements  for 
real-time  programming,  and  interfacing  to  other  languages."  Since  validated  versions  of 
Ada9X  will  probably  be  available  by  the  time  the  ARWA  project  is  completed,  conversion 
to  a  fully  object-oriented  design  using  Ada  is  a  possibility  for  the  ARWA  program.  In  the 
meanwhile,  steps  can  be  made  to  design  the  ARWA  software  to  increase  the  possibility  of 
conformance  to  the  Ada9X  standard. 

3.3.  Reuse  level  analysis. 

Each  reuse  option  mentioned  in  sections  3.1  and  3.2  has  been  evaluated  according  to  its 
reuse  maturity  level.  Three  levels  are:  opportunistic,  systematic,  and  automatic  generation. 

The  opportunistic  level  is  the  least  mature  level  that  yields  the  least  amount  of  reusable 
products  for  the  effort  it  involves.  The  user  searches  for  reusable  parts  in  an  ad  hoc 
manner,  mainly  at  the  lowest  level  of  abstraction,  i.e.,  code.  There  may  or  may  not  be  a 
central  reuse  repository  in  which  to  find  these  parts.  The  ones  that  exist  usually  contain 
parts  that  are  not  relevant  to  the  project,  are  not  tailored  for  reusability,  are  not  thoroughly 
tested,  and  do  not  follow  the  same  standards.  The  user  usually  relies  on  past  experience, 
private  libraries,  and  notes  to  perform  design  and  development  activities. 

The  systematic  level  involves  a  well-defined  and  repeatable  process  with  organizational 
commUmeuLs  for  funding,  sfaffing,  and  incentives  for  production  and  use  of  reusable, 
workproducts.  Clear  ceiiification  of  parts  and  configuration  management  procedures  are 
byproducts  of  systematic  level  reuse.  In  systematic  reuse,  the  project  schedules  have  more 
time  allotted  to  the  requirements  and  design  activities,  but  shorter  development  times  to 
accommodate  more  rapid  prototyping  at  the  framework  level.  Sophisticated  library  tools 
are  not  required,  just  logical  directory  structures  with  high  quality  parts  relevant  to  the 
domain. 

The  automatic  generation  level  cannot  happen  without  the  foundation  of  the  systematic 
level.  Systems  arc  literally  built  while  in  tlie  requirements  and  design  phases  with  the  aid 
of  application  generators.  The  most  basic  generators  include  4GLs  and  User  Interface 
Generators.  The  Cadre  Teamwork  CASE  tool  provides  some  basic  code  generation 
capabilities.  More  complex  generation  tools  operate  at  higher-levels  in  order  to  hide  the 
manual  interconnection  of  components  via  a  problem-oriented  language,  template,  option 
filler,  or  visual  programming  environments  (such  as  in  the  G2  tool,  made  by  Microsoft). 
Internal  domain  expertise  is  needed  to  set  up  the  application-specific  parts  and  relate  them  to 
framework  dc.sigus  and  specific  requirements.  Tae  output  is  usually  code  and/or 
procedural  calls  in  a  higher  order  language. 

3.3.1.  Assumptions. 

The  assumptions  in  this  analysis  are: 
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a.  There  is  a  natural  progression  of  mature  reuse  processes  that  involve  increasing 
organizational  commitment  and  more  effective  usage  of  the  application  experts' 
skills. 

b.  The  Government  may  become  involved  to  incentivize  such  activities  in  order  to 
make  the  producers  more  willing  to  produce  reusable  software. 

3.3.2.  Reuse  level  model. 

The  reuse  level  model  focuses  on  the  maturity  of  the  reuse  process.  Three  distinct  levels 
(opportunistic,  systematic,  and  automatic  generation)  ate  described  in  3.3.  If  viewed  on  a 
continuum  from  least  mature  (opportunistic)  to  most  mature  (automatic  generation),  the 
following  characteristics  would  apply: 

Least  Mature 

No  standards 
Manually  search  and  use 
Small  artifacLs 

Low  level  of  abstraction,  e.g.,  code 

Nonrepeatable  usage 
Different  vocabulal^ 

No  metrics 
Shmt-teim  reuse 
Unplanned 

Disjointed  semi-ieusable  artifacts 
Low  quality  artifacts 
No  training 

Domain  knowledge  not  recorded 
Little  management  support 
No  reuse  organization 
Scattered  focus  on  reuse  applications 
Savings/costs  not  tracked 
Poor  communication  about  reuse 
resources 


Most  Mature 

Many  standards 
Auluinalic  assistance  search 
Large  artifacts 

High  level  of  abstraction,  e.g.. 

frameworks 
Highly  repeated  usage 
Same  vocid)ulary 
Reuse  metrics 
Long-term  reuse 
Planned 

Relational  groupings  artifacts 
High  quality  artifacts 
Training 

Domain  knowledge  recorded 
Management  commitment 
Reuse  organization 
Well-defined  reuse  areas 
Savings/costs  tracked 
Good  communication  about 
reuse  resources 


With  this  continuum  in  mind,  each  reuse  option  was  rated  according  to  the  following  scale: 

Reuse  Level  Ratine  Scale 

1  =  Low 

2  =  Average 

3  =  Above  Average 

4  =  Excellent 

5  =  Superior 

3.3.3.  Procedures. 

An  expert  assesses  the  reuse  level  of  each  option  using  the  ranking  values  described  above. 
The  results  are  tabulated  in  a  summary  table. 

3.4.  Reuse  quality  analysis. 

Each  reuse  option  mentioned  in  sections  3.1  and  3.2  is  evaluated  according  to  the  resulting 
quality  of  reuse. 


(Opportunistic) 

(Ad  hoc  with  some  systematic  activities) 
(Systematic) 

(Systematic  with  some  automatic  generation) 
(Automatic  generation) 
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3.4.1.  Assumptions. 

The  assumptions  duiing  this  analysis  are: 
a.  Quality  parameters  that  affect  reusability  are: 

-  Correctness 
-Usability 

-  Adaptability 

-  Robustness 

-  Independence 

-  Understandability 
-Portability 

-  Testability 

-  Accessability 

-  Performance 

Correctness  is  the  degree  a  product  fulfills  its  requirements  in  a  consistent  manner.  This 
parameter  i.s  ensured  by  inspections,  thorough  testing,  number  of  prior  reuses,  or 
some  otlier  certification  process. 

UscAUity  is  the  extent  to  which  the  product  will  need  to  be  modified  to  fit  into  another 
context  Minimal  modiHcation  is  desired. 

Adaptability  is  the  speed  and  ease  in  which  a  {mniuct  may  be  tailored  to  fit  into  another 
context 

Robustness  is  the  length  of  time  a  product  is  Suable  as  a  reusable  product,  e.g.,  S 
years,  20  years,  etc. 

Independence  is  the  degree  to  which  the  prodm  is  self-contained,  i.e.,  is  standalone  and 
docs  not  depend  upon  other  artifacts  for  inputs, 
f/iu/emundlabi/tty  is  the  level  of  clarity  inherent  in  the  product  The  product  is  structured 
logically  with  complete  documentation. 

Portability  is  the  ease  in  which  a  product  is  porred  to  another  hardware  platform  or 
soi'twarc  language. 

Testability  is  the  ease  in  which  a  product  is  tested  in  a  standalone  or  integrated  situation. 
Accessability  is  the  ease  of  acquiring  the  product  for  reuse.  For  example,  a  product  has 
high  accessibility  when  located  within  the  project's  local  file  system  t^t  is  clearly 
labeled. 

Perfotmance  is  the  amount  of  effect  the  product  has  on  the  system's  performance  when 
included  in  the  system's  framework. 

3.4.2.  Reuse  quality  model. 

Since  reuse  quality  has  many  facets,  a  Kiviat  Diagram  is  used  to  visually  show  the 
differences  in  quality  by  showing  whether  a  reuse  activity  would  produce  a  certain  reuse 
quality  in  the  developed  product  Each  "spoke"  in  the  diagram  represents  one  of  ten 
parameters  and  exhibits  a  quality  rating.  The  quality  rating  scale  for  how  well  the  reuse 
candidate  fulfills  tlic  quality  parameter  is  as  follows: 

Reuse  Quality  Rating  Scale 

1  =  None 

2  =  Below  average 

3  =  Satisfactory 

4  =  Above  average 

5  =  Superior 

The  ratings  are  connected  by  a  line  and  the  resulting  shape  shows  the  quality  profile.  The 
larger  the  enclosed  area,  the  higher  the  quality.  An  example  of  this  diagram  is  shown  in 
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figure  3.  For  ease  of  comparison  with  the  other  analyses,  an  average  of  the  10  parameters 
will  be  used  to  iei»resent  a  particular  reuse  option. 

3.4.3.  Procedures. 

An  expert  assesses  the  reuse  quality  of  each  option  using  the  ranking  values  described 
above.  The  results  are  first  tabulated  in  a  Kiviat  Diagram  and  then  averaged  for  display  in 
the  summary  table. 

3.5.  Reuse  cost  impact  analysis. 

Each  reuse  option  mentioned  in  sections  3.1  and  3.2  is  evaluated  according  to  the  resulting 
initial  cost  impact  and  future  savings  related  to  each  option. 

Reuse  cost  implementation  depends  upon  the  producer-user  scenario.  For  example,  there 
is  a  cost  to  m^ng  something  more  reusable  and  a  cost  for  reusing  something.  The  cost 
decreases  when  more  mature  levels  of  reuse  are  implemented  and  when  artifacts  are  reused 
mure  lhaii  once. 


3.5.1.  Assumptions. 

The  assumptions  used  in  this  analysis  are: 

a.  There  are  different  productivity  ratios  for  those  who  only  produce  reusable  artifacts, 
produce  and  use  once,  use  once,  produce  and  use  many  times,  and  use  many  times. 


Sample  Kiviat  Diagram 


Figure  3.  Sample  Kiviat  Diagram 
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b.  There  is  an  initial  cost  impact  to  create  a  reusable  artifact 

c.  The  cost  to  use  a  reusable  artifact  may  be  greater  or  less  than  the  cost  to  build  it 
depending  upon  the  quality  of  the  artifact  and  the  skill  of  the  user. 

d.  Actual  cost  estimates  cannot  be  calculated  because  the  labor  rates  and  processes  are 
different  for  the  producers  and  the  consumers. 

3.5.2.  Reuse  cost  model. 

The  in-house  cost  model  is  similar  to  the  commercial  System  Evaluation  and  Estimation  of 
Resources  (SEER)  model.  Part  of  the  in-house  costing  process  uses  the  SEER  model 
results  as  a  sanity  check  on  the  results.  At  the  beginning  of  a  project,  the  delivered  pix>duct 
size  is  estimated  and  each  LOG  is  associated  with  a  productivity  rate  depending  upon  what 
type  it  is.  The  productivity  ratio  is  defined  as  the  ratio  of  hours  per  line  of  c^e.  Higher 
productivity  is  associated  with  the  lower  values.  Table  5  contains  an  example  of  this 
classification  schema: 


Code  Type 

Code  Subtyne 

Productivity  Ratio 

NewLOC 

New  application  code 

.95 

Non-delivered  code 

.35 

Reused  LOC 

Added  code 

.32 

Changed  code 

.09 

Deleted  code 

05 

Unmodified  code 

.03 

Ported  code 

.08 

COTS  integration  code 

.25 

Table  5.  Example  Reuse  Cost  Schema 


To  use  this  model  would  require  data  in  smaller  granularity  than  is  available  at  this  time. 
Therefore,  for  this  study,  a  simpler  approach  is  used  that  entails  assessing  the  initial  cost 
impact  to  implement  a  particular  reuse  option,  estimating  the  productivity  increase  using  the 
SFC's  scale,  and  averaging  the  two  rates. 
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Process  or  Tool 

Productivity  Increase 

Magnitude  of 
Cost 

Compiler  Library 

1  (10  %) 

2 

Operating  System 

1  (10  %) 

2 

Scavenge 

1  (10  %) 

1 

Junk  Yard 

1  (10  %) 

1 

Re-Engineering 

3  (30  %) 

1 

Parts  Library 

3  (40  %) 

2 

Extensible  Framework  (ba.sed  on  Domain 
Analysis) 

5  (120  %) 

2 

Synthesis  (Automatic  Generation  +  Domain 
Analysis) 

5  (250  %) 

3 

Table  6.  Reuse  Cost  and  Productivity  Scale 


Table  6  shows  the  relative  productivity  increases  and  cost  impacts  for  various  types  of 
reuse  processes/tools  based  on  data  from  the  SPC  [Durek  89]  according  to  the  following 
rating  scales: 

Maaiitude  of  Cost  Impact  Ratine  Scale: 

1  =  Extremely  High  (more  than  24  labor  months) 

2  =  High  (12 -24  labor  months) 

3  =  Medium  (6  - 12  labor  months) 

4  =  Low  (1-6  labor  months) 

5  =  Very  Low  (0-1  labor  month) 


Prodwtivity  inggase-Eatiogjicsis: 

1  =  Very  Low  (0  - 10  %) 

2  =  Low  (11-30%) 

3  =  Medium  (31-50%) 

4  =  High  (51-100%) 

5  =  Very  High  (greater  than  100  %) 


3.5.3.  Procedures. 

An  expert  assesses  the  reuse  level  of  each  option  using  the  ranking  values  described  above. 
Tlie  results  are  tabulated  in  a  summary  table. 
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This  high  level  analysis  indicates  the  impact  on  the  project  schedule  for 

phase  2  of  the  ARWA  project  for  each  reuse  option  implementation  mentioned  in  sections 

3.1  and  3.2. 


3.6.1.  Assumptions. 


The  assumptions  in  this  analysis  are  that* 

a.  Estimates  are  based  on  preliminary  design  information. 

b .  Task  dependencies  that  are  logical. 

c.  The  schedule  is  impacted  less  if  the  activity  is  on  a  non-critical  path. 

d.  These  are  generic  situations  tacked  on  to  current  project  schedules  that  may  become 
a  standalone  project. 

3.6.2.  Reuse  schedule  impact  model. 


In  a  more  detailed  analysis,  each  reuse  option  would  have  a  skeleton  work  breakdown 
structure  and  a  sample  schedule  would  be  plotted  into  PERT  charts.  The  inputs  would  be 
validated  by  actual  developers  from  the  Loral  team.  For  the  sake  of  time,  expert  estimates 
are  used  to  assess  the  amount  of  time  and  labor  involved  to  implement  each  option  and  rank 
their  impacts  based  on  the  following  scale: 


Schedule  Impact  Ratine  Scale 
1  =  Extremely  high 
2=  Somewhat  high 
3=  Medium 
4=  Low 
5=  None 


(more  than  1  year) 

(6  months  - 1  year) 
(3-5  months) 

(2  weeks  -  2  months) 
(0-2  weeks) 


3.6.3.  Procedures. 


An  expert  assesses  the  reuse  level  of  each  option  using  the  ranking  values  described  above. 
The  results  are  tabulated  in  a  summary  table. 

4.0  Results. 


This  sections  contains  the  results  of  each  of  the  four  analyses  used  to  evaluate  the  reuse 
implementation  options  descrilied  in  section  3.2.  The  summary  of  tlie  analysis  results  is 
contained  in  table  9.  Equal  weighting  is  assumed  for  each  analysis.  Tlie  option(s)  with  the 
highest  average  rating  is  the  most  optimal  choice. 

4.1.  Reuse  level  analysis. 

The  reuse  level  rating  scale  is  as  follows: 


Reuse  Level  Ratine  Scale 

1  =Low 

2  =  Average 

3  =  Above  Average 

4  =  Excellent 


(Opportunistic) 

(Ad  hoc  with  some  systematic  activities) 
(Systematic) 

(Systematic  with  some  automatic  generation) 
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5  =  Superior  (Automatic  generation) 

Option  1  (current  reuse  activities)  is  ranked  as  a  2.5.  This  approach  is  mote  than  just  ad 
hoc  because  several  systematic  activities  are  happening  such  as,  internal  reuse  from  past 
projects,  coordination  of  common  software  among  the  team,  tracking  the  amount  of  reuse 
via  LOG  metrics,  and  following  a  generic  simulator  architecture.  With  the  addition  of  some 
mote  reuse  activities,  this  option  would  become  a  3  (systematic  level). 

Option  2  (independent  study  suggestions)  is  ranked  as  a  2.  The  suggestions  are  a  gentle 
push  towards  systematic  reuse,  but  are  not  enough  to  achieve  that  level. 

Option  3  (Ada  style  guidelines)  is  ranked  as  a  2.  Incorporating  standards  for  the  code  is 
just  one  activity  out  of  many  towards  achieving  systematic  reuse. 

Option  4  (port  to  Ada)  is  ranked  as  a  2.  This  small  step  has  a  positive  impact  on  not  only 
the  current  project,  but  future  reuse  opportunities  in  that  the  code  will  be  incorporated  more 
easily  because  it  is  in  the  same  language.  Performance  will  not  degrade  because  of  multiple 
compilers  and  so  forth. 

Option  5  (domain  analysis)  ranks  as  a  3.  This  is  the  core  activity  of  systematic  reuse. 
Domain  expertise  gets  captured  and  efforts  may  be  focused  on  products  that  bring  the 
greatest  return  on  investment. 

Option  6  (object-oriented  design  conversion)  is  ranked  as  a  4.  This  conversion  is  a 
systematic  activity  that  requires  training  and  may  involve  software  tools  for  quicker 
documentation.  Object-oriented  testing  involves  a  different  approach  than  testing  structured 
code.  More  scenarios  and  a  wider  variety  of  tests  are  required. 

4.2.  Reuse  quality  analysis. 

The  numerical  results  are  contained  in  table  7.  These  results  are  graphically  displayed  via 
Kiviat  Diagrams  shown  in  figure  4.  The  quality  gradually  improves  from  option  1  to 
option  6.  Options  3  and  4  are  closely  related.  It  is  assumed  that  the  port  to  Ada  involves 
conformance  to  the  Ada  Style  Guidelines.  The  quality  rating  is  expressed  in  table  7 
according  to  the  following  rating  scale; 

Reuse  Quality  Rating  Scale 

1  =  Nonc 

2  =  Below  average 

3  =  Satisfactory 

4  =  Above  average 

5  =  Superior 


1994 
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Parameters 

Opt  1: 
Current 
Actions 

Opt  2: 
Indep. 
Studies 

Opt  3: 

Ada 

Guide. 

Opt  4: 
Port  to 
Ada 

Opt  5: 
D^ain 
Anal. 

Opt  6: 
OOD 

Correemess 

2 

4 

3 

3 

5 

5 

Usability 

4 

4 

4 

5 

5 

5 

Adaptability 

4 

4 

5 

5 

5 

5 

Robustness 

3.5 

3 

5 

5 

5 

5 

Independence 

4 

3 

5 

5 

5 

5 

Understandability 

2.5 

4 

5 

5 

5 

5 

Portability 

3 

3 

5 

5 

3 

5 

Testability 

3 

4 

3 

4 

4 

4 

4 

3 

3 

3 

4 

4 

Performance 

3 

3 

3 

4 

3 

4 

AVERAGE 

3.3 

3.5 

4.1 

■SB 

4.4 

mm 

Table  7.  Reuse  Quality  Analysis  Results 


4.3.  Reuse  cost  impact  analysis. 

Cost  impact  was  taken  to  be  an  average  of  the  initial  labor  cost  and  the  predicted  reuse 
level.  A  summary  of  the  reuse  cost  impact  analysis  is  shown  in  Table  8  according  to  the 
following  rating  scales: 


Initial  Cost  Impact  Rating  Scale: 

1  =  Extremely  High 

2  =  High 

3  =  Medium 

4  =  Low 

5=  Very  Low 


(more  Uian  24  labor  raontlis) 
(12  -  24  labor  months) 

(6  - 12  labor  months) 

(1-6  labor  months) 

(0-1  labor  month) 
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Option  1  -  Current  Activities  Option  4  -  Port  to  Ada 


UndmtandMty  UMmiMMiy 


Option  2  -  Independent  Studies  Option  5  -  Domain  Analysis 


UnOmtxdUiaty  UwiMUBdrtaiir 


Option  3  -  Ada  Style  Guide  Option  6  -  Object-Oriented 


UndnunMiity  UndnUndMIly 

Figure  4.  Quality  Results  Kiviat  Diagrams 


(Opportunistic) 

(Ad  hoc  with  some  systematic  activities) 
(Systematic) 

(Systematic  with  some  automatic  generation) 
(Automatic  generation) 


1  =Low 

2  =  Average 

3  =  Above  Average 

4  =  Excellent 

5  =  Superior 
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Reuse  Option 

Iiutial  Cost 
Impact 

Predicted  Reuse 
Level 

Average  Cost 
Input  Rating 

1.  Current  Reuse 

Activities 

5 

2.5 

5.75 

2.  Independent  Study 
Suggestions 

5 

2 

3.5 

3.  Ada  Style  Guidelines 

5 

2 

5.5 

4.  Port  to  Ada 

4 

2 

3 

5.  Domain  Analysis 

3 

5 

3 

6.  Objeci-Oiienled  Design 
Conversion 

2 

4 

3 

Tnbk  8.  Reuse  Cost  Impact  Analysis 


4.4.  Reuse  schedule  impact  analysis. 

As  a  reminder,  the  rating  scale  for  the  reuse  schedule  impact  analysis  is  as  follows; 


Schedule  Impact  Rating  Scale 
1  =  Extremely  high 
2=  Somewhat  high 
3  s:  Medium 
4=  Low 
5  =  None 


(more  than  1  year) 

(6  months  - 1  year) 
(3-5  months) 

(2  weeks  -  2  months) 
(0-2  weeks) 


Option  1  (current  reuse  activities)  is  ranked  as  a  4.  All  of  the  activities  are  short  tasks. 

Option  2  (independent  study  suggestions)  is  ranked  as  a  4.  The  analysis  of  the  functions 
requires  the  most  amount  of  time. 

Option  3  (Ada  .style  guidelines)  is  ranked  as  a  4.  Verification  of  following  the  guidelines 
takes  the  most  time. 


Option  4  (port  to  Ada)  is  ranked  as  a  1.  Translation  of  more  than  lOOK  LOC  requires  a 
substantial  effort 


Option  5  (domain  analysis)  ranked  as  a  3.  Much  of  the  functional  analysis  has  already  been 
done 


Option  6  (object-oriented  design  conversion)  is  ranked  as  a  2.  Much  of  the  domain 
analysis  and  functional  analyses  can  be  used  as  a  foundation  and  timesaver  for  this  task. 
Also,  in-house  object-oriented  experts  may  act  as  consultants  to  make  this  analysis  go  even 
more  quickly.  Designer/dcveloper  object-oriented  training  still  needs  to  occur  and  thi.s  is 
what  dnves  out  the  schedule.  Training  takes  one  week,  but  productivity  would  be  initially 
slower  until  the  concepts  take  hold;  thus,  the  lower  ranking. 
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Reuse  Option 

Reuse 

Level 

Reuse 

Quality 

Cost 

Impact 

Schedule 

Impaa 

Average 

Rating 

1.  Current  Reuse 

Activities 

2.5 

3.3 

3.75 

4 

3.39 

2.  Independent  Study 
Suggestions 

2 

3.5 

3.5 

4 

3.25 

3.  Ada  Style  Guidelines 

2 

4.1 

3.5 

4 

3.40 

4.  Port  to  Ada 

2 

mm 

3 

1 

2.60 

S.  Domain  Analysis 

3 

mm 

3 

3 

3.35 

6.  Object-Oriented  Design 
Conversion 

4 

4.7 

3 

2 

3.43 

Table  9.  Summary  of  Reuse  Analyses 


5.0  Conclusions  and  recommendations. 


5.1  Summary  of  conclusions  and  recommendations. 

There  are  two  views  of  reuse  in  this  study:  1)  using  reusable  artifacts  to  build  and  test  the 
system  being  developed  and  2)  ensuring  that  a  portion  of  the  system  will  be  reusable  in  the 
future.  The  Loral  team  must  act  both  as  a  consumer  and  a  producer  in  the  reuse  world. 
The  reuse  analyses  performed  in  this  study  provide  some  guidance  for  accomplishing  the 
most  reuse  (short-term  and  long-term)  with  tte  least  impact  to  cost  and  schedule. 

According  to  the  results,  the  least  productive  option  is  to  port  the  system  to  Ada  and  the 
next  to  least  effective  option  is  to  follow  the  siig^tions  put  forth  in  the  independent  study 
papers.  The  top  options,  beginning  with  the  best  choice,  are:  object-oriented  conversion, 
adopting  the  Ada  Style  Guidelines,  performing  current  reuse  activities,  and  performing  a 
domain  analysis  on  the  system.  The  top  options  improve  the  chances  for  long-term  reuse. 
These  are  intermediate  level  (systematic)  activities.  If  domain  analysis  and  object-oriented 
design  are  performed,  it  will  be  feasible  and  cost-effective  to  perform  automatic  generation 
of  uaining  simulators  using  Commercial-Ofl-The-Shelf  (COTS)  tools  and  domain  experts. 

The  most  immediate  and  feasible  activity  for  performing  a  domain  analysis  would  be  to 
start  with  the  ARWA  kits  for  RAH-66  and  AH-64D  to  determine  a  generic  architecture, 
modeling  equations,  and  data  format  Variable  features  would  be  noted  for  the  object- 
oriented  design. 

The  most  logical  means  of  transitioning  to  an  object-oriented  design  is  to  pursue  the  Boeing 
Domain  Architecture  for  Reuse  in  Training  Systems  (DARTS)  methodology  [Boeing  93]. 
The  DARTS  architecture  is  essentially  a  merging  of  Boeing's  ModSIM  architecture  with  tte 
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Software  Engineering  Institute's  Air  Vehicle  Structural  Model  (AVSM)  architecture.  The 
ModSIM  architecture  deHnes  modular  segments  of  a  training  system  and  the  interfaces 
between  those  segments.  The  AVSM  architecture  deHnes  tihe  subsystems  within  each 
segment  and  the  interfaces  between  those  subsystems. 

Thus  far.  the  ARWA  preliminary  design  effort  has  produced  a  ModSIM  design,  with 
clearly  defined  segments  and  interfaces.  A  transition  from  the  ModSIM  architecture  to  the 
DARTS  architecture  at  this  point  would  be  relatively  smooth  since  much  of  the  internal 
workings  of  the  segments  have  yet  to  be  defined,  ^fort  spent  thus  far  on  defining  the 
system  under  the  ModSIM  architecture  could  be  utilized  completely  in  a  transition  to  the 
DARTS  architecture. 

Transitioning  to  the  DARTS  architecture  at  this  point  in  time  makes  a  great  deal  of  sense  for 
the  ARWA  project  In  order  to  keep  the  intrasegment  functionality  and  interfaces  consistent 
between  MDHS  and  Boeing,  a  standard  methodology  needs  to  be  chosen.  Since  DARTS 
is  compatible  with  ModSIM,  it  meets  the  goal  of  providing  standard  intrasegment 
de^itions  while  retaining  the  design  worked  on  thus  far.  The  DARTS  architecture 
produces  an  object-abstracted  design,  and  DARTS  architectured  software  will  allow  for 
reusable  software  witMn  segments. 

The  modules  of  the  ARWA  SS  which  utilize  existing  reusable  software  in  its  current  state 
include  the  Weapons,  Flight  Dynamics;  Sensor  Control  and  ASE  modules.  The  TNE 
(environment)  and  Flight  Control  modules  also  have  reuse  potential  In  order  to  encourage 
future  reuse  of  these  modules,  the  customer  should  require  a  separate  Contract  Data 
Requirements  List  (CDRL)  item  for  these  modules  that  contain  reuse  instructions,  e.g., 
what  to  change  or  not  change.  The  VSM  and  FSM  have  been  desired  to  be  reusable 
within  the  constraints  of  a  ModSIM  architecture,  though  no  existing  code  has  been 
identified  to  be  reused.  Reuse  will  come  about  through  careful  design  and  documentation. 

5.2  Lessons  Learned. 

Appendix  A  describes  the  search  for  models  and  data  to  help  validate  the  system.  These 
resources  uncovered  some  reusable  modules  for  the  ARWA  project,  but  nut  as  many  as  had 
been  hoped  for. 

The  best  source  for  reusable  artifacts  were  found  within  the  contractor’s  software  and 
documentation  from  previous  related  projects.  Since  there  is  a  lot  of  internal  reuse 
occurring,  the  customer  should  require  a  CDRL  item  that  captures  the  reu.se  successes  and 
failures. 

The  current  ARWA  approach  is  certainly  a  viable  solution  to  producing  reusable  software  at 
a  reasonable  cost.  Changes  to  an  object-oriented  design  through  domain  analysis  have 
been  shown  to  be  cost  efficienL  The  simplest  and  most  effect  means  to  transition  to  an 
object-oriented  approach  would  be  to  incorporam  the  DARTS  methodology. 

6.0  Notes. 

This  section  contains  a  glossary  of  key  terms  and  an  acronym  list. 


6.1  Glossary 


Automated  Reuse.  Software  reuse  accomplished  via  the  use  of  application  generators 
to  build  new  applications  from  high  level  descriptions.  Examples  include  4GLs  and  User 
Interface  Generators. 
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Domain  Analysis.  The  process  of  identifying,  collecting,  organizing,  analyzing,  and 
representing  a  domain  mo^l  and  software  architecture  from  the  study  of  existing  systems 
underlying  theory,  emerging  technology,  and  development  theories  within  tte  domain  of 
interest 

External  Reuse.  Reuse  of  workproducts  produced  in  one  project,  consumed  by 
another.  External  reuse  level  is  measured  by  comparing  units  written  against  units  taken 
from  an  explicit  external  library  at  that  abstraction  level. 

Framework.  A  set  of  workproducts  or  infrastructure  that  behaves  as  a  skeletal  system  or 
application  and  implements  the  common  functionality  in  an  architecture.  A  framework 
provides  a  shell  for  the  systematic  development  and  interconnection  of  woritproducts, 
ensuring  common  appearance  and  behavior  via  use  of  common  services. 

Generator.  A  higher-level  automatic  builder  that  hides  the  manual  interconnection  of 
components  using  a  problem-oriented  language,  template  or  option  filler,  or  a  visual 
programming  environments.  Hie  generator  enables  concise  specification  of  the  desired 
(piece  of  the)  application,  and  then  generates  appropriate  code  and/or  procedure  calls  in 
some  other  language. 

Generic  Application.  A  cuslomizable.^extendible  application  that  captures  most  of  the 
interesting,  common  parts  of  an  application  domain,  a  complete  application  is  built  by 
adding  missing  parts,  adjusting  parameters,  or  selecting  alternative  components.  It  is  often 
built  upon  an  application  framewoik.  It  can  also  be  a  prototypical  or  skeletal  application, 
consisting  of  &e  infrastructure,  some  components,  and  some  preset  interconnection 
language  scripts,  to  simplify  the  task  of  creating  complete,  conforming  applications  for 
some  domain.  This  may  be  just  a  shell,  into  which  additional  components  should  be 
plugged  to  produce  an  executable  application,  or  may  be  a  trivial,  but  complete  application 
that  needs  to  be  evolved  into  the  frnal/desired/customized  application  via  the  addition  or 
replacements  of  components  and  changes  in  interconnection  language. 

Internal  Reuse.  Avoiding  redundant  implementation  of  functionality  within  a  single 
project  by  careful  design  and  inspection  at  early  stages  such  that  selected  components  are 
identified  for  distinct  uses  within  the  project  system  or  subsystem. 

Opportunistic  Reuse.  Reuse  through  identification  of  previously  unplanned-for 
opportunities  to  reuse  workproducts. 

Reusability.  An  attribute  of  software  workproducts  that  measures  the  degree  to  which 
they  can  be  used  in  more  than  one  computer  program  or  .software  system. 

Systematic  Reuse.  The  planned  reuse  of  workproducts  with  a  well-defined  process 
and  lifecycles,  with  commitments  for  funding,  staffing,  and  incentives  for  production  and 
use  of  reusable  workproducts. 
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6.2  Acronym 

ADST 

ARWA 

AVCATT 

CECOtA 

COTS 

CSCI 

FSM 

GIT 

IDA 

LOG 

ModSAF 

ModSIM 

PERT 

SEER 

SEI 

SPC 

SS 

SSM 

SSS 

STRICOM 

SW 

TNE 

TWSTIAC 

VSM 

WDL 


List 

Advanced  Distributed  Simulator  Training 

Advanced  Rotary  Wing  Aircraft 

Aviatitm  Combined  Aims  Tactical  Trainer 

U.S.  Army  Communications-Electronics  Command 

Commeicial-ofT>the-shelf 

Computer  Software  Component  Iton 

Flight  Station  Module 

The  Georgia  Institute  of  Technology 

Institute  for  Defense  Analyses 

Lines  of  Code 

Modular  Semi- Automated  Forces 

Modular  Simulator  System 

Program  Evaluation  and  Review  Technique 

System  Evaluation  and  Estimation  of  Resources 

Software  Engineering  Institute 

Software  Productivity  Consortium 

Simulator  System 

Simulation  Software  Module 

System/Segment  Specificmimi 

Simulation,  Training,  and  IiLstrumcntation  Command 

Software 

Tactical  &  Natural  Environment  Module 
Tactical  Warfare  and  Simulation  Technology  Information  Analysis 
Center 

Visual  System  Module 
Loral  Western  Development  Labs 
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APPENDIX  A 

REPOSITORIES  CHECKED  FOR  REUSE  INFORMATION 
10.  Introduction 

Loral  has  identified  models  for  potential  reuse  in  the  ARWA  simulation.  From  this  model 
list,  repositoty  sites  have  been  searched  for  availability  to  make  an  initial  top-level  judgment 
of  reusability.  Table  1  contains  the  list  of  models  and  data. 

Numerous  repositories  for  reusable  data,  documentation,  and  source  code  for  the  ARWA 
program  have  been  searched.  These  include: 

1)  ASSET  Source  for  Software  Engineering  Technology 

2)  Z^fense  Software  Repositoiy  System  (DSRS) 

3)  Modeling  and  Simulation  Information  System  (MSIS) 

4)  Document  Cataloging  System  (DOCATS) 

5)  Army  Reuse  Center  (ARC) 

6)  She^on,  Inc. 

7)  Sparta,  Inc. 

8)  Public  Ada  Library  (PAL)  (Ada  Software  Repository) 

9)  Ada  Joint  Program  Office  (AJPO)  and  AdalC 

10)  National  Technical  Information  Services  (NTIS) 

11) AdaNET 

Various  categories  of  inforr  .ati  jn  for  each  source  are  given  as  follows: 

1)  Description  -  A  brief  description  of  the  source 

2)  Data  Search  -  Infoimation  about  search  perfonned 

3)  Findings  -  Results  of  search 

4)  Rating  -  Reusability  rating  of  repository 

The  general  criteria  categories  for  rating  tlie  reuse  data  repositories  were: 

1)  Available  relevant  software  models 

2)  Available  relevant  ducumentaiion 

3)  Cost,  data  rights,  and  electronic  access 

A  score  of  0  (worst)  to  10  (best)  has  been  given  to  each  category  and  a  final  score  has  been 
tabulated  for  each  source. 


System 

Flight  Control 

Primary  Controls 

✓ 

✓ 

Flight  Director 

✓ 

✓ 

Landing  Gear  Doors 

✓ 

✓ 

✓ 

Flight  Controls  Loading 

✓ 

✓ 

AFCS 

✓ 

✓ 

Velocity  Stabilization 

✓ 

Table  Al.  List  of  ARWA  Models  and  Data 
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HARS/AHRS 


DNS 


GPS 


ICS 


VHFCOMMS 


UHFCOMMS 


Air  Data 


ATHS 


Linc-of-siglu  and  range  aitentuation 
models  and  data 


Movin 


Area  Wesqxxi  System 


Aerial  Rocket  System 


Point  Target  System 


Heat  Seeking  Missiles 


Hit/Kiil  Probability,  models  &  data 


PNVS 


HIDSS 


MMW  Radar 


Sensor  degradation  based  on  atmospheric 
conditions  including  smcke,  fog.  and  rain 


RFI 


Material  Emissivtv  Model 


INU 


Imegraied  with 
GPS 


CCP 


ARC-1S6 

ARC-201 


ARC-164 


ADS 


ARC-186 

ARC-201 

HF 


EATHS  upto 
IOC  Baud 


20  mm  gun 


Hydra  70 
2.75"  RKTS 
MK-66 
MPSM 


AGM-114 
Hellfiie 
Laser  Seeker 


ATAS 


EOTADS 

AN/ASQ-170 

FLIR 

DIY 

ATD/C 

LRF/D 

LST/IAT 


NAV/TSD 


M-230EI 
30  mm  gun 


2.75"  RKTS 
MK-66 
MPSM 


AQ4-114A 
Hellfire 
RF  Seeker 
Laser  Seeker 


ATAS 


AN/AAQ-11 

FLIR 


AN/ASQ-170 

FLIR 

DTV 

DVO 

LRF/D 

LST/IAT 


Table  Al.  List  of  ARWA  Models  and  Data  [Continued] 
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Aifcnft  Suvivability 
Equqiiieot 


Flight  Dynamics 


Physical  Cues 


Radar  Wanung 


LaserW 


Radar  Wamin 


Chemical  Wamin 


Radar  Jammer 


IR  Jammer 


Chaff 


Flare 


Equations  of  Motion 
Mass  Properties 
Main  Rotor  Aerodynamics 
Blade  element 
Rotor  maimed  disc 


LilJiJQ. 

lIZnEMESSSS 


Aiffiame  Aerod 


Ground  Handlin 


Main  and  Tail  Rotor  S 


Transmission 


Transmission  Oil  Tern 


Transmission  Oil  Pressure 


Gas  Generator/Power  Turbine 


Oil  Tem 


Engine  Oil  Pressure 


Available  Torque 


Turbine  Gas  Temperature 


Aircraft  warning,  radar  and  navigation 
system  tones 


Synthetic  voice  message 


Voice  communcadon 


Fuel  System 


Master  Caution 
AVarning  system 


APR-39 

APR-4S 

APR-39 

(V)l 

(V)2 

APR-48 

AVR-2 

AVR-2 

Table  Ai.  List  of  ARWA  Models  and  Data  [Continued] 
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System 

mxiism 

VSM 

Head  tracking  pcedictkMi  algorithms 
dampening 
smoothine 

V 

Line  of  Sitht/Rav  tracine  alamithms 

t/ 

✓ 

Databases 

✓ 

Movins  Model  Icons 

✓ 

Intervisibilitv 

7 

✓ 

TNE 

OwnsbtD  collision  detection 

7 

7 

Dead  Reckonine 

7 

7 

AOIsoeenina 

7 

✓ 

Intervisibilitv 

✓ 

✓ 

La.scr  Ranee  Findine 

7 

✓ 

Atmosohere/Maenetic  Variation 

✓ 

✓ 

Table  Al.  List  of  ARWA  Models  and  Data  [Continued] 


1 1 .  Reuse  Sources 

The  following  sources  were  searched  and  the  results  of  the  searches  are  given: 

11.1  Asset  Source  for  Software  Engineering  Technology  (ASSET) 

11.1.1  Description 

ASSET  is  a  software  reuse  library  and  reuse  information  exchange  available  to  software 
developers  in  government,  industry,  and  education.  ASSET  is  sponsored  by  ARPA's 
STARS  (Software  Technology  for  Adaptable,  Reliable  Systems)  Program  to  serve  as  a 
national  resource  for  the  advancement  of  software  reuse  across  the  DoD.  The  ASSET 
library,  located  in  Morgantown,  WV,  is  connected  to  the  Internet  allowing  world-wide 
access  to  reusable  software  assets. 

11.1.2  Data  Search 

A  .sciries  of  pattern  searches  were  performed  on  the  ASSETS  catalog  document  using  key 
words  for  the  ARWA  model.  The  results  of  these  searches  is  documented  below. 

Keyword:  "navig" 

ASSET_A_396  Pai  ser  I*  uilder  Software  Bundle 

ASSET_A_30 1  Roams  Test  Report  &  Lessons  Document  Learned. 

Keyword:  "communi” 

ASSET_A_247  ADA  Composer.  ADA  Design  Tool  Software  Bundle 

using  OOD. 

ASSET_A_157  ADA  Runtime  Support  for  Complex  Software  Tool 

Time  Critical  Embedded  Applications. 

ASSET_A_345  ARPC  (Augmented  Remote  Procedure  Software 

Bundle  Call) 
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ASSET_A_5 17  Cleanroom  Engineering  Handbook  &  Document 

Specification  Team  Practices. 

ASSET_A_415  Environmental/Tool  Integrator  User  Software 

System  Manual. 

ASSET_A_224  Information  Objea  Modeling  Example  Software 

Bundle  for  Air  Traffic  Control. 

♦Some  potential  for  applicability  to  the  ARWA  program. 

ASSET_A_330  Inter-Tool  Communications  Facility  Software 

Bundle  (ITCF). 

ASSET_A_167  Inter-Tool  Communications  Facility  Document 

(TTCF)  Rnal  Report 

ASSET_A_381  Paradise  Document 

ASSET_A_303  Process  Modeling  Document 

aSSFT_A„3  1 9  Process  Notation  Development  AAA  Document- 

Mag.  Noiation  Article 

ASSEr_A„324  Q  an  ADA/C/Interprocess  Document 

Communications  Support  Utility 

ASSET_A_503  Quality  Function  Deployment  Software  Bundle 

ASSET_A_227  Remote  Procedure  Cali  Toolkit  (RPC)  Software 

Tool 

ASSET_A_175  Requirements  Elicitation  Process  Document 

ASSET_A_48 1  RIG  Basic  Interoperability  Data  Model 

Document 

ASSET_A_301  Secure  File  Transfer  Program  (SFTP)  Document 

ASSET_A_232  SEE  Demonstration  Report  Software  Tool 

Report 

ASSET_A_323  Software  Engineering  Courseware,  Document 

University  of  Cincinnati 

Keyword:  "flight" 

ASSET_A_356  ADA/Operating  System  Interface  Software  Bundle 

Keyword:  "controls" 

ASSEr_A_l(X)  GNU  SED  (Batch  Stxemu  Editor)  Software  Tool 

ASSET_A_328  UATL  (Universal  ADA  Test  Language)  Document 

Keyword:  "weapons" 
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ASSET_A^32S  Software  Reuse  Case  Study  (Trillium)  Document 
Keyword:  "dynamic" 

ASSET_A  ji29  Dynamic  Array  Package  Document 

ASSET_A_108  Environment/Tool  Integrator  Software  Component 

ASSET_A.226  Planning  and  Optimization  Tools  Software  Tool 

ASSET_A_439  Tailorable  ADA  Runtime  Environment  Document 

(TARTE) 


ASSET_A_234  Terminal  Interface  Package  Software  Bundle 
Keyword:  "physical" 

ASSET_A_475  ROAMS  Testbed  Report  and  Lessons  Document 
Le^ed 


Keyword:  "simulation" 

ASSET_A_5 19  Cleanroom  Engineering  Handbook:  Document 

Organization  and  Ihoject  Formation 
in  the  Cleanroom. 


ASSET_A_252 

ASSET_A_412 

ASSET_A_323 

ASSET_A_353 


Event  Set  Manager  Package  Document 

External  String  Management  Package  Software- 
Component 

Software  Engineering  Courseware,  Document 
University  of  Cinciimati. 

Software  Measurement  Guidebook  Courseware 


ASSET_A_2 18  Tasking  ADA  Simulation  Kit  (TASKTT)  Sofrivare 
Bundle 


ASSET_A_234  Terminal  Interface  Package,  Building 

Software  Bundle  Blocks 

ASSET_A_307  Tools/Notation  Evalu^on  Report  Document 

Pn)to  Process  Model. 


ASSET_A_308  Transparent  Distributed  ADA  Runtime  Document 

Support 

There  were  no  occurrences  of  the  following  keywords  in  the  ASSET  Catalog: 


"sensor" 
"aircraft" 
"surviv" 
"propulsion" 
"physical  cues" 
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"cues" 

"cue" 

"queue" 

"fuel  system" 

"electrical  ^stem" 

"hydraulic" 

"caution" 

"warning" 

"head  tracking" 

"line  of  si^t" 

"line-of-sight" 

"moving  model" 

"intervisibility" 

"atmosphere" 

"dead  reckoning" 

"range  finding" 

"collision" 

11.1.3  Findings 

Though  many  documents  and  software  were  found  for  some  keywords,  most  of  the 
important  ARWA  keywords  led  to  no  information  found.  Of  the  documents  and  software 
found,  many  of  it  is  not  applicable  to  the  ARWA  program.  There  is  little  software  or 
documentation  that  the  ARWA  program  can  utilize  from  ASSETS. 

11.1.4  Rating 


Available  relevant  software  models:  2 

Available  relevant  documentation:  2 

Cost,  data  rights,  and  electronic  access  8 

Total  score:  4.00 


11.2  Defense  Software  Repository  System  (DSRS) 

11.2.1  Description 

DSRS  (formerly  RAPID)  is  an  automated  library  of  reusable  software  development 
components  avr^able  to  the  DoD  and  other  Government  agencies,  including  supporting 
contractors. 

11.2.2  Data  Search 

DSRS  was  searched  for  the  keyword  "mass  properties"  by  the  Army  Aviation  Warfighting 
Center  at  Ft.  Rucker,  AL.  The  following  components  were  returned: 

MAPAC_Ada_Transf_FFT_Radix8 

MAPAC_Ada_Transf_FFT_Radix8_Lookup_Table 

MAPAC_Ada_Transf_FFT_Radix2_Lookup_Table 

MAPAC_Ada_Transf_Init_FFl_Lookup_Table 

MAPAC_Ada_Transf_Inverse_FFT..Radix2 

MAPAC_Ada_Transf_lnverseJFFT_Radix2_Lookup_Table 

MAPAC_Ada_Transf_lnverse_FFT^Radix4 

MAPAC_Ada_Transf_Inverse,FFT_Radix4_Lookup_Table 

MAPAC_Ada_Transf_Invetse_FFT^Radix8 

MAPAC_Ada_Transf_Inverse_FFTJladix8_Lookup_Table 
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MAPAC_Ada_Transf_ScalejCoraplex_By_VectorJLength 

MAPAC_Ada_Transf_Scale_Coinpiex_Vect_To_Abs_Arap 

MAPAC_Ada_Transf_Scale_Mairix_By_Rows_X_Columns 

MAPAC_Ada_Transfonn_Pac 

MAPAC_ada_Lin_Gen_Decompose 

MARC_MATRIX_AUTOMATED_REDUCnON  AND  COUPLING 
MASPROP_MASS_PROPERTIES_OF_A_RIGID_STRUCTURE 
MATHEMATICAL  ROUTINES.FOR  ENGINEERS  AND  SCIENTISTS 
MAXIMUM/MINIMUM_ENVEOPE_PLOTS 
MEL21_Pipe_Flexibility_Program_(CDC  Version) 
MEL21_Pipe_Flexibility_Program_(IBM  Version) 

MEL2  l_Pipe_Flexibility_Program_(Univac  Version) 

11.2.3  Findings 

Of  the  integrated  models  searched  for  with  the  keyword  "mass  properties",  the  MASPROP 
MASS  PROPERTIES  OF  A  RIGID  STRUCTURE  component  seems  to  have  the  most  use 
for  the  ARWA  program. 

11.2.4  Rating 


Available  relevant  software  models:  2 

Available  relevant  documentation:  2 

Cost,  data  rights,  and  electronic  access  8 

Total  score:  4.00 


11.3  Modeling  and  Simulation  Information  System  (MSIS) 

11.3.1  Description 

The  Tactical  Warfare  and  Simulation  Technology  Information  Analysis  Center  (TWSTIAC) 
Modeling  and  Simulation  Information  Systems  (MSIS)  is  sponsored  by  the  Defense 
Modeling  and  Simulation  Office  (DMSO).  The  DMSO  MSIS  is  an  on-line  service  available 
to  a  large  audience  of  subscribers  from  government,  the  military  services,  academia,  and 
indust^,  and  is  designed  to  serve  the  Modeling  and  Simulation  (M&S)  community  by 
providing  current  leading  edge  information  on  what  is  happening  in  the  M&S  community. 
The  Cat^ogs  of  Models  and  Simulations  features  mformation  to  the  subscriber  on  models 
and  simulations  from  all  the  services,  the  joint  staff,  and  TRANSCOM.  The  type  of  data 
available  in  this  menu  includes  the  Point  of  Contact  (POC),  date,  description,  parameters, 
uses,  and  computer  requirements  data  for  the  several  hundred  models  listed. 

11.3.2  Data  Search 

Loral  obtained  the  entire  list  of  models  available  from  MSIS.  The  sources  of  these  models 
are  War  Games,  Training  Games  &  Combat  Simulation;  J-8  M&S  Catalog;  MOSAIC 
(Models  &  Simulations:  Army  Integrated  Catalog);  Navy  Catalog  of  Models  and 
Simulations;  TRANSCOM  System  Model  Catalog;  and  US  Air  Force  Rome  Laboratory 
M&S  Catalog.  Roughly  1000  models  exist  in  these  repositories.  The  AVCATT  library 
was  searched  for  various  models  by  the  Army  Aviation  Warfighting  Center  at  Ft  Rucker, 
AL.  The  following  components  were  returned: 

ARTOAR  -  Attack  Helicopter  Air-to-Air  Fire  Control  System 

Simulation  Model 

HPROBI  -Hit  Probability 
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PS-2 

HEUPAC 

HAVDEM 

HELSCAM 

HELMATESn 

GPS  Map  System 
11.3.3  Findings 


-  Propulsion  System  Performance  Simulation 

-  Helicc^ter  Piloted  Air  Combat  Model 

-  Helicopter  Air-to-air  Value-Driven  Engagement  Model 

-  Helicopter  Scenario  Assessment  Model 

-  Helicopter  Launched  Missile  Antitank  Effectiveness 
Simulation 

-  Global  Positioning  System  M^  System 


The  AVCATT  search  proved  very  useful  in  locating  not  only  documentation  sources,  but 
also  software  sources.  Many  software  models  from  this  repository  can  be  utilized  in  the 
ARWA  device. 


11.3.4  Rating 

Available  relevant  software  models:  7 

Available  relevant  documentation:  7 

Cost,  data  rights,  and  electronic  access  9 

Total  score:  7.67 


11.4  Document  Cataloging  System  (DOCATS) 

11.4.1  Description 

The  Document  Cataloging  System  (DOCATS)  is  a  data  base  that  identifies  all  documents  in 
the  CCTT  library.  This  data  base  lists  the  document  name,  author  name,  date,  abstract, 
keywords  and  other  pertinent  data  that  help  to  identify  sources  of  information.  In  addition 
to  searches  on  these  fields,  searches  by  weapon  system  name  and  use  of  Boolean  operators 
(and,  or,  not)  are  available  to  narrow  or  broaden  the  search.  Once  a  document  is  identified, 
a  copy  can  be  obtained  by  identifying  the  unique  document  number  and  title. 

11.4.2  Data  Search 

Loral  visited  Resource  Consultants,  Inc.,  the  company  in  charge  of  the  Close  Combat 
Tactical  Trainer  (CCTT)  library.  A  search  was  made  on  AVSCOM  AH-64,  RAH-66, 
RWA,  Sim  Models.  Missiles.  lIVLaser,  and  Weapon  System  Performance.  Roughly  5  to 
10  documents  under  each  category  were  found. 

11.4.3  Findings 

Only  documentation  was  available  -  no  software  models.  DOCATS  is  not  a  great  source  of 
ARWA  information.  The  POC  at  RCI  is  Judith  DeNicola,  (407)282-151. 

11.4.4  Rating 

Available  relevant  software  models:  0 

Available  relevant  documentation:  3 

Cost,  data  rights,  and  electronic  access  6 
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Total  score:  3.00 

11.5  Army  Reuse  Center  (ARC) 

11.5.1  Description 

The  Army  Reuse  Center  (ARC)  is  a  primary  focal  point  for  reuse  within  the  Department  of 
the  Army.  The  ARC  was  established  to  support  the  development  and  fielding  of  reliable, 
high  quality  systems  while  reducing  the  time  and  resources  required  to  develop  and 
maintain  those  systems.  The  mission  of  the  Army  Reuse  Center  is  to  develop,  implement, 
maintain,  and  actoinister  a  total  reuse  program  that  will  support  the  entire  software 
development  life-cycle  (SDLC).  At  the  heart  of  the  Army  Reuse  Onter  is  an  automated 
library  system  that  provides  user  access  to  a  wide  range  of  high  quality  reusable  software 
components.  The  library  currently  contains  over  2400  reusable  design,  code,  and 
document  components  and  represents  over  1.8  million  lines  of  code. 

11.5.2  Dalu  Search 

Loral  obtained  the  Army  Reuse  Center  catalog.  A  non-disclosure  agreement  needed  to  be 
signed  in  order  to  obtain  any  of  the  information  in  the  Army  Reuse  Center.  Loral  desired 
changes  to  the  non-disclosure  agreement  to  cover  legal  issues,  but  the  Army  Reuse  Center 
explained  that  a  lengthy  review  would  be  necessary  for  this  to  happen.  A  non-disclosure 
agreement  was  therefore  not  signed  by  LoraL 

11.5.3  Findings 

Since  a  non-disclosure  agreement  was  not  signed  by  Loral,  the  Army  Reuse  Center  data  is 
unattainable  at  this  time. 

11.5.4  Rating 
Unranked. 

11.6  Sherikon,  Inc. 

11.6.1  Description 

Sherikon,  Inc.  is  under  contract  under  PM  CATT  to  catalog  documentation  for  both  RAH- 
66  and  AH-64  aircraft, 

11.6.2  Data  Search 

Loral  visited  the  Sherikon  office  in  Orlando,  FL.  and  asked  ic  see  the  library.  'I  he  library 
is  still  being  constructed  and  no  document  listing  has  been  produced. 

11.6.3  Findings 

Only  documentation  was  available  -  no  software  models.  Sherikon  could  be  a  source  of 
information  once  the  library  becomes  operational.  The  POC  at  STRICOM  is  Bob  Hale, 
(407)380-4986. 

11.6.4  Rating 

Available  relevant  software  models;  0 

Available  relevant  documentation;  1 
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Total  score:  2.00 

n.7  SPARTA,  Inc. 

11.7.1  Description 

SPARTA  performs  the  V&V  for  the  ARWA  project  SPARTA  has  ai^ved  data  bases 
and  in-house  models  which  can  be  used  on  me  ARWA  program  to  wdate  sensor  and 
weapon  modules.  These  models  were  approved  by  AMSAA,  Night  Vision  BSD,  and 
ARL.  SPARTA  has  incorporated  these  models  and  data  bases  into  ALWSIM  and  can 
exercise  that  simulation  for  validation  tasks.  Standalone  versions  of  some  models  can  also 
be  used  for  validation. 

11.7.2  Data  Search 

SPARTA  Validation  Models: 

Sensors: 

ACQUIRE  Search  &  Target  Acquisition 
FUR  90  FLIR  performance 

IMAGE  INT.  Image  Intcn.<dficr  Pcrfomiancc/TV  Performance 
PHI  Laser  Target  Acquisition 
TARGET  CONTRAST  Optical  Contrast 

Weapons: 

INDIRECT  FIRE  EFFECTS  HE/ICM  Pk 
INCURSION  AD  Effects  -  Guns  &  MissUes 
GAMES  Smart  Munition  Effects 
LELAWS  Laser  Weiq)on  Effects 
DMEWS  HPM  Weapon  Effects 

Environment: 

EOSAEL  Natural  Atmosphere,  Smoke,  Dust 
SPARTA  Validation  Data  Basrw: 

Weapons: 

DIRECT  FIRE  Accuracy  (Bias,  Dispersion) 

DIRECT  FIRE  Vulrwrabilily,  Fk/HIT 
DIRECT  FIRE  Timeliness 
DTRRCT  FIRE  Vehicle  Characteristics 
INDIRECT  FIRE  Delivery  Accuracy  (MPL  Precision) 

INDIRECT  FIRE  Lethal  Area 

Scenarios: 

HRSl,  HRS29,  HRS  14 

11.7.3  Findings 

Only  models  for  performing  V&V  ate  available. 

11.7.4  Rating 

Available  relevant  software  models:  8 
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Available  relevant  (tocumentation:  5 

Cost,  data  rights,  and  electronic  access  S 

Total  score:  6.00 

11.8  Public  Ada  Library  (PAL)  (Ada  Software  Repository) 

11.8.1  Description 

The  Public  Ada  Library  (PAL)  is  a  collection  of  Ada  programs,  tools,  and  educational 
materials.  Source  code  can  be  retrieved  over  tl^  Internet  via  FTP  (wuarchive.wustl.edu). 

11.8.2  Data  Search 

Loral  obtained  the  PAL  catalog  of  reusable  software  from  wuarchive.wustl.edu.  The 
listing  of  software  components  included  ^reen  routines,  math  libraries,  and  simple 
algorithms.  The  listing  of  software  develofHnent  tools  included  many  Ada  analysis  tools. 

11.8.3  Findings 

The  basic  software  components,  though  not  ARWA  specific  models,  could  be  used  in 
some  applications  for  the  ARWA  program.  Software  develc^ment  tools  could  also  be  used 
to  some  extent 

11.8.4  Rating 


Available  relevant  software  models:  2 

Available  relevant  documentation:  3 

Cost,  data  rights,  and  electronic  access  8 

Total  score:  4.33 


1 1.9  Ada  Joint  Program  Office  (AJPO)  and  AdalC 

11.9.1  Description 

Source  code  from  some  AJPO-^onsored  projects  is  available  through  the  Ada  Information 
Clearinghouse  and  the  AJPO  host  (ajpo.sei.cmu.edu)  on  the  Internet  Source  code  may  be 
retrieved  via  FTP. 

11.9.2  Data  Search 

A  listing  of  available  documentation  and  software  was  retrieved  from  the  AJPO  Internet 
address. 


11.9.3  Findings 

Very  limited  software  is  available.  The  documentation  centered  around  Ada  standards. 

11.9.4  Rating 


Available  relevant  software  models:  1 

Available  relevant  documentation:  1 

Cost  data  rights,  and  electronic  access  7 

Total  score:  3.00 
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11.10  National  Technical  Information  Servi<%s  (NTIS) 

11.10.1  Description 

NTIS  is  a  self-supporting  publishing  agency  for  the  U.S.  Department  of  Commerce.  It 
provittes  a  free  catalog  of  the  software  available  from  the  Federal  Computer  Products 
Center,  which  is  a  clearinghouse  for  over  3500  products  from  about  100  Federal  agencies. 

11.10.2  Data  Search 

Loral  obtained  the  NTIS  catalog  of  software. 

11.10.3  Findings 

Software  has  limited  rights  and  has  cost  involved.  An  ARWA  software  search  turned  up 
the  following  potentiaUy  reusable  software  mocfels: 

Communications  model:  Terrain-Integrated  Rough-Earth  Model  (TIREM), 

$140,  Point-to-point  radio  transmission  loss 
Navigation  model:  Mapping  Datum  Transformation  Software 

(MADTRAN),  $55,  Coordinate  conversion  program 

No  ARWA  documentation  was  available. 

11.10.4  Rating 

Available  relevant  software  models:  2 

Available  relevant  documentation:  0 

Cost,  data  rights,  and  electronic  access  6 

Total  score:  2.67 

11.11  AdaNET 

11.11.1  Description 

AdaNct  is  a  component  of  the  Repository  Based  Software  Engineering  (RBSE)  program 
sponsored  by  NASA.  RBSE  is  a  research  and  development  program  designed  to 
effectively  hansfer  software  engineering  technology  among  U.S.  government,  industry, 
and  academia.  The  purpo.se  of  RBSE  i.s  to  support  the  adoption  of  .software  reuse  through 
rep-'-itory-based  software  engineering.  The  program  provides  a  repository  that:  facilitates 
the  selection,  acquisition,  integration,  and  reuse  of  software  components;  and  promotes 
common  software  engineering  practices  and  standards.  The  AdaNET  Repository  currently 
contains  reusable,  public  domain  software  from  the  following  sources: 

-  Ada  Software  Repository  (Army/ASR) 

-  Jet  Propulsion  Lab  (NASA/JPL) 

-  DoD/STARS 

-  Educational  Institutions. 

The  following  collections  are  available  on  AdaNet. 

AdaNet  Collections: 

1.  AI/Expert  Systems.SF 

2.  ASV3  SupportSG 
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3.  Education.SH 

4.  Human  Rated  Sysiems.SI 

5.  Image  Processing  and  Analysis.SJ 

6.  Information  ManagementSK 

7.  Language  Features  and  Constnicts.SL 

8.  Legal  Issues.SM 

9.  Library  Interfaces  and  Piotocols.SN 

10.  Lifecycle  Methods  and  Tools.SO 

11.  Metrics.SP 

12.  Routines  and  Alg(Mithms.SQ 

13.  Standards.SR 

14.  System  SupportSS 

15.  User  Interfaces.ST 

16.  Samples.su 


11.11.2  Data  Search 

Loral  is  a  member  of  AdaNET.  The  above  collections  were  searched,  and  there  were  no 
models  directly  applicable  to  the  ARWA  project  There  are  some  generic  math  algt^dims 
and  some  metrics  availabte  which  may  be  somewhat  useful. 

11.11.3  Findings 

Not  very  many  models  are  available  for  the  ARWA  project 

11.11.4  Rating 


Available  relevant  software  models:  1 

Available  relevant  documentation:  0 

Cost,  data  rights,  and  electronic  access  8 

Total  score:  3.00 


12.  Conclusions 

The  final  ratings  are  ordered  as  foUov/s: 

7.67  Modeling  and  Simulation  Information  System  (MSIS) 

6.00  Sparta,  Inc. 

4.33  Public  Ada  Library  (PAL)  (Ada  Software  Repository) 

4.00  Elefense  Software  Repository  System  (DSRS) 

4.00  ASSET  Source  for  Software  Engineering  Technology 

3.00  Ada  Joint  Program  Office  (AJPO)  and  AdalC 

3.00  Document  Cataloging  System  (DOCATS) 

3.00  AdaNET 

2.67  National  Technical  Information  Services  (NTIS) 

2.00  Sherikon,  Inc. 

Unranked  Army  Reuse  Center  (ARC) 

These  rankings  reflect  the  level  of  reusability  of  existing  data  for  the  ARWA  program. 
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[MSIS] 

[CATn 

[ARC] 


The  Modeling  and  Simulation  Information  System  brochure. 
Institute  of  Simulation  and  Training. 

CATT  Data  Base  Support  Libraries  brochure,  STRICOM 

Army  Reuse  Center  brochure.  Army  Reuse  Center 
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APPENDIX  B 

REUSE  DESIGN  AND  CODING  GUIDELINES 
20.  Introduction 

This  set  of  reuse  guidelines  for  designs  and  code  is  based  on  published  industry  and  in- 
house  reports  and  documentation.  Most  of  the  guidelines  are  generic  and  non-language 
specific,  except  where  noted.  The  sequence  of  guidelines  does  not  imply  rank  or 
importance.  This  listing  is  an  overview  only.  Detailed  definitions,  descriptions,  and 
examples  are  provided  in  the  references  associated  with  each  guideline.  Finally,  the 
purpose  of  this  list  is  to  provide  a  standard  set  of  guidelines  to  be  used  within  Loral  and  by 
its  subcontractors  for  the  ARWA  project 


2 1 .  Design  Guidelines 


1.  Component  Structure  [Lea  93] 

a.  Identify  and  encapsulate  commonalty  and  variability. 

b .  Separate  interfaces  and  implementations. 

c.  Identify  and  isolate  context  and  policy  from  functionality. 

d.  Link  documentation  to  code. 

e.  Link  tests  to  code. 

f .  Use  tools  when  target  languages  do  not  support  sufficient  interface,  composition, 
and/or  parameterization  constructs. 

2.  Interfaces  [Lea  93] 

a.  Minimize  the  number  of  names  per  name  space  (scope). 

b .  Minimize  implementation-dependence  of  interfaces. 

c .  Refine  interfaces  by  extending  and  adding  properties. 

d.  Optimize  components  via  specialization. 

3.  Composition  [Lea  93] 

a.  Identify  and  minimize  import  requirements. 

b .  Identify  and  minimize  interference  among  helpers. 

c .  Use  layering  to  define  complex  components  using  simple  ones. 

d .  Implement  policy  on  top  of  mechanism. 

4.  Parameterization  [Lea  93] 

a.  Use  parameterization  to  abstract  away  contextual  variability. 

b .  Use  instantiation  to  generate  components. 

5.  Isolate  the  hardware,  software,  and  database  management  system  implementation 
functions.  [Hooten  89] 

This  allows  minimum  impact  when  enhancing  or  correcting  the  system. 
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6.  Extend  the  design  to  encompass  the  entire  set  of  end  users,  i.e.,  software  developers, 
maintainers,  and  reusers.  [Hooten89] 


7.  Isolate  all  hardware  and  operating  system  (tepenctencies.  [Hooten  89] 

These  typ^  of  “calls”  should  be  packaged  in  small  software  interface  routines  that 
can  be  tailored  to  the  environment  or  replaced  with  equivalent  modules  in  a 
subsequent  environment 


8.  Isolate  items  which  are  likely  to  change.  [Hooten  89] 

9.  Don’t  plan  to  reuse  software  components  that  have  to  be  modified  more  than  30  percent, 
but  extract  design  and  algorithmic  details  instead.  [Hooten  89] 

10.  Keep  interfaces  as  simple  and  application-nonspecific  as  possible 

1 1.  Think  in  higher  levels  of  abstractions  for  functions,  data,  and  processes. 

[Alexandria  86] 

Function  abstractions  (e.g.,  subprogram  interface  specifications)  are  designs  based 
on  the  user  only  being  aware  of  the  input-output  specification  while  the 
implementation  is  hidden  from  the  user.  The  same  function  may  be  reused  for  a 
variety  of  data. 

Data  abstractions  (e.g.,  Ada  packages)  are  designs  in  which  the  data  and  several 
function  implementations  are  hidden  from  the  user,  possibly  with  superimposed 
hierarchical  inheritance  on  data  abstractions,  facilitating  dynamic  determination  of 
the  function  to  be  invoked.  Data  objects  may  be  reused  for  various  operations  that 
may  be  applied  to  them. 

Process  abstractions  (e.g..  Ada  tasks)  operate  like  data  abstractions,  only  they  have 
an  independently  executing  thread  of  control  that  determines  the  order  in  which 
operations  become  available  for  execution  and  include  concurrent  processes  that 
may  communicate  through  shared  data  in  global  memory  and  distributed  processes 
tiiat  communicate  by  message  passing. 


12.  Design  more  for  flexibility,  not  generality.  [Parnas  et.  al.  89] 

Allow  for  easy  modifications  within  the  domain  that  are  reasonable  to  occur  in  tlic 
future,  not  every  possibility.  This  would  make  the  code  too  cumbersome  and 
slow. 


22.  Coding  Guidelines 
22.1  General 


1.  Keep  modules  small  and  simple,  i.e.,  minimize  the  number  of  functions  per  module. 
[Hooten  89] 


2.  Each  module  should  contain  clear  documentation  regarding  its  purpose,  capabilities, 
constraints,  interfaces,  and  requited  resources.  [Hooten  89] 
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3.  Whenever  possible,  use  a  portable,  high-order  programming  language.  [Hooten  89] 


4.  Avoid  compiler-specific  instructions.  [Hooten  89] 

5.  Adhere  to  common  coding  standards,  conventions,  and  styles.  [Hooten  89] 

6.  Don’t  assume  that  a  given  feature  is  present  or  not  present  in  the  system.  [Pamas72] 

7.  Avoid  chains  of  data  transforming  components.  [Pamas72] 

A  chain  of  data  transforming  components  is  a  sequence  of  components,  each 
receiving  data  from  the  previous  component  and  then  processing  the  data  into 
another  format  for  the  next  component  When  the  chain  is  broken,  the  inputs 
become  incompatible. 


8.  Minimize  the  “uses”  structure.  [Pamas  72] 

One  may  end  up  with  a  system  in  which  nothing  works  until  everything  works. 
For  example,  while  it  may  seem  wise  to  have  an  operating  system  scheduler  use  the 
file  system  to  store  its  data  rather  than  use  its  own  disk  routines,  the  result  will  be 
that  the  file  system  must  be  present  and  working  before  any  task  scheduling  is 
possible. 

9.  Clearly  document  all  error  conditions.  [Hooten  89] 

10.  Isolate  machine-dependent  operations.  [Hooten  89] 


11.  Isolate  operating  system-dependent  operations.  [Hooten  89] 

12.  Isolate  database  management  system-dependent  operations.  [Hooten  89] 

13.  Use  non-exotic  algorithms,  whenever  possible.  Otherwise,  be  sure  to  fully  document 
the  algorithm  in  the  specification  or  some  other  visible  place  in  the  code.  [Hooten  89] 

14.  Avoid  table  size  constraints.  [Hooten  89] 


22.2  Ada  Language 


1.  The  specification  (portion  of  code  that  defines  and  initializes  the  program  variables)  must 
be  readable  and  understandable.  It  must  be  well  documented  so  as  to  fully  describe  each 
parameter  that  it  uses  and  its  interfaces  to  other  packages.  [Hooten  89] 

2.  Use  information  hiding  techniques.  System  details  that  are  likely  to  change 
independently  should  be  hidden  in  the  bodies  and  assumptions  unlikely  to  change  should 
be  placed  in  the  specification.  [Pamas  et  al.  89] 

For  example,  every  data  structure  is  private  to  one  module;  it  may  be  directly 
accessed  by  one  or  more  programs  witl^  the  module  but  not  by  programs  outside 
tire  module.  Any  odier  program  that  requires  information  stored  in  a  module’s  data 
structures  must  obtain  it  by  calling  prog^s  on  the  module  interface. 
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